(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCX) 



(19) World Intellectual Property 
Organization 



:ll!IIIIIIIIEI!lilllli9ii|lli|llliilP1llllll1lli|llll 



143) Inli-i national Publication Date (10) International Publication Number 

24 February 2005 (24.02.2005) PCX WO l\m A2 



(SI) International rVtenLCIassifieathm 7 : H04 L 29/00 

(21) Interna Lionai Application Numher: 

K:i7iJS20(S4A)2fi264 

International Filing Date; 1 2 Aagnst 2004 (12.08.2004) 

(25) Filing language: English 

(26) Publication Language: English 

(30) Priority Data: 

NM Hm 13 Alii MM (( I, _ US 

(Ti) Applicant > i" i 't < > ' < . - 

COMM. [NCOKPOKATKD |US/US|; 5.775 Morehouse 
SB Drive, San Diego. Cdifojr.fc GGG171 i USi 

iii (75) ImveiilM's/Applicants y„- i.'i OTj/vj: ANDERSON, Jon, 
.tunics i (.!>/■ :> ]; IT-e igu-.|;i Ore c. H-.- :l-:.!or. (. Vkmidc, 
= 80301 (ITS).. STEELE, Brian [ITS/TTS]: 1074 Tllad Way. 
= I silbvcLfc, Colorado mm .(IIS). WIL^Y, George, Alan 



HB5/IJSI; 5740 Brillimy IWsl I amp San Diego. Calilbr 

slia 92130 (US). SHLkDAR. Shashaiik JK 

- el I Lip 1 i 1 ( I in 1 21 US), 

(74) Agents: WADS WORTH, Philip R. et al; 5775 More- 
haise Drive, -San l>e^p CalilCrme 92121-1714 (US). 

(81) Designated States »«»./. . < , t .m/,c ./',:/ jot eier.v 
ki'iti i>; i r i ' , \y \(i vl AM. 

AT. AU. AZ, HA. MB, BG, BR. I! W, BY. BZ, CA, CH. UN. 

co, cr, cu, cz, di m dm •/ i'i: loes.fi, 

OB, QD. GB. Oil. GM, IIR, TTU, ID, IL. IN. TS. .TP, ICE. 
KG, KP, KR, KZ. I.C, LK, TJR, LS, LT, LU, LV, MA, MD, 
MCI, MK, M.N. VI W, MX. MX, NA. Nl. NO, NZ.OM, it I, 
1'H, PL, PL', RO, RU, SC, SD, SLi, SG, SK, SL, SY, TJ, TM, 
TN.IK.T1.TZ. LA. LG. L S. UZ.VL.VK, YU.ZA.ZM. 
ZW. 

(84) Designated Slate* (mil,:,* <,i!i<:m;> t itidksk-J, for every 
kind ofregirm:,! pmlrnien nwifohhr. AKIPt > (I!VV, fill, 
GM, KB. LS, MW. MZ, NA, SD, SL, SZ, TZ, UG, ZM, 
/W> GtrdsGnt A\!. A / H V. MS. KZ. Ml). HI.. 1.1. TM t, 
Trreee:, , (AT, FT. BG. CD. -Gil CZ. DC, DIG CF. CS. FT. 
1-R,GB, GR.HUJH, !T, I.U, MC ; NL, Pi ,, IT, RO,Sli,SI, 



jj :54> Title; A SIGNAL IN llifU ACL K>R liiGliLcR DATA RAILS 



portable 
_ computer _ 
wireless" 

TELEPHONE 
PDA 



FORWARD D IRECTION 



REVERSE DIRECTION 



C Af-,;,tr,i.;l,: A T-p int.::!; i.,: Tor piinG-nine eTpt.i ,i„!l,i Kpe.etn ,i [.up end a client e,vei eo.E,nt iniardon 
t t r I r 'efiGtcr t t ■ n i 1 1 tvt i I i c 1 f . mil 'i : i r I it i i i \ z mtn 

tic, The siprad prc.cicol i-, . sed by lick ce.nlv, Hers c;i,dpp,red I;, ee'ieane e-„re;init. jirie reueive packeLs form; 

ac-or tiiorc types of data, packets, with it Cast: one rcsidiig it 1 1 
s ["■;. til Tie TterG;e .) feei.Z:'.-; ; : ; e.'.qi-etTiXTive. low ptvw 
short-TnriiES ''rtsrisV' tvp^ ilfils 'in:;, v-'htcS lend', itGf te i-.npleinentiiti 
flexible cables which are especially uselul in connecl-Rg display eierneni,-. such as wearabie 
portable computers anil wirGei-s .. -.imtm etion devices. 



O i iu 1 1 t i r, it n jAjG 
(""^ In iih> i i 1 i G It ii lie. 
Q high-speed tin t tt m tr nce h 'r' - 



WO 2005/018191 A2 IPiE II II liPlinillllflllil lliiii I'll 



SK. 1'R), OAPI (HI', BJ, CK CXi, CI, CM, OA..GN, <5Q, 
GW, ML, MR. NE, SN, ID, TG). 

IJcdjnjfiiiii!' muter RuIb 4.17: 

— as to apph ^ - r ' i i itid be granted 

,j :„>;■:■!, ,Ruh 'i.i'isii'i ih,~ foiinwinz Jtiigfir.dws Ah, 
AG. At, AM, AT, AU, AZ, BA. BB, BG, BR, BW. BY. BZ 
CA, CH, CIV, - CO. CR, CU, CZ Ot. UK, DM, DZ EC, EE. 
EG, ES, FI, GB, GD, GE. GH, GM, HR, HU, ID. IL. IN, IS. 
IP. KE, KG. KP. KR. KZ, I.C. IX. !.R. IS. IT. W. IV. MA, 
MO, MG A/A V t , \ Mi 1/ 

i'ir pa n, i'i ha in Sk V> -, , n 

'I'M, TN, TR, IT, 'IX. UA, EG. !•/., W, V.N, Yli, /A. /M. 
7.W, ARIPO patent (BW. Oil. GM KE. IS, MW, MZ. AM, 
SO, SI, SZ. 17, IIC. 7.M, 7.W), Eurasian patent (AM, AZ, 



RK KG, KZ. W). F.I I, TJ, TM\. Put t ipwi p.mr | . A-\ RF. 
BG, CU. CX CZ, DE, DE, EE. ES, EL ER, GB, GR, 1IU, IE, 
EL L'J. MC. M. PL, PI, RO, iE. SI. SK. IE:. OAPI f^n-tu 
:BF BJ CE Co, CI, CM. CA, CV CO. OVA MI MR, rAF. 
SN, TO, TG) 

— as to the «// ' ' '.• ci,iP(p,*h; , > ,< , >• » n of the 

c.aiicr 4v/.. , ,;v;j. : yij; ■; K:iA: l.:.Ai<Ai!: for J.:::ii-?Ki!i,:n., 
Published: 

— Yj'ithoui it'"- I- i • ' of <. bf tfi.f /■ /,l<' 
i >c»i rt eipt }l ■!, ; vpm ' 

I Ay n ,i h m > 1 f ' ir'nr i> • > i ' >: r-fAr tn th "Guid- 
j ( ! 1 1 1 1 i , r i i ( 

V ' i r i 1 ' ' r , r 1 *- > ' Cl -i tfr' 



WO 2005/018191 



] S2004/026264 



A SIGNAL INTERFACE FOR HIGHER DATA RATES 

CROSS-MEIHERENGE TO RELATED APPLICATIONS 

[0001 J The present Application for Patent claims priority to Provisional Application No. 

60/494,983 entitled "MDDI Specification Advancements" filed August. 13, 2003, and 
assigned to the assignee hereof and hereby expressly incorporated by reference herein. 

BACKGROUND 

I. Field 

[0002] Embodiments of the invention in this disclosure relate to a digital signal protocol 

and process for communicating or (xansferring signals between a host device and a client 
device at high data rates. More specifically, the disclosure relates to a technique for 
transferring multimedia and other types of digital signals from a host or controller device to 
a client device for presentation or display to an end user using a low power high data rate 
transfer mechanism having internal and external device applications. 

II. Background 

[0003] Computers, electronic game related products, and various video technologies, (for 

example DVD's and High Definition VCRs) have advanced significantly over the last few 
years to provide for presentation of increasingly higher resolution still, video, video-on- 
demand, and graphics images, even when including some types of text, to end users of such 
equipment. These advances in turn mandated the use of higher resolution electronic 
viewing devices such as high definition video monitors, HDTV monitors, or specialized 
image projection elements. Combining such visual images with high-definition or -quality 
audio data, such as when using CD type sound reproduction, DVDs, and other devices also 
having associated audio signal outputs, is used to create a more realistic, content rich, or 
true multimedia experience for an end user. In addition, highly mobile, high quality sound 
systems and music transport mechanisms, such as MP3 players, have been developed for 
audio only presentations to end users. This has resulted in increased expectations for 
typical users of commercial electronics devices, from computers to televisions and even 
telephones, now being accustomed to and expecting high or premium quality output... 

[0004] In a typical video presentation scenario, involving an electronics product video data 

is typically transferred using current techniques at a rate that could be best termed as slow 
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or medium, being on the order of one to tens of kilobits per second. This data is then either 
buffered or stored in transient or longer-term memory devices, for delayed (later) play out 
on a desired viewing device. For example, images may be transferred "across" or using the 
Internet using a program resident on a computer having a modem or internet connection 
device, to receive or transmit data useful in digitally representing an image. A similar 
transfer can take place using wireless devices such as portable computers equipped with 
wireless modems, or wireless Personal Data Assistants (PDAs), or wireless telephones. 
[0005J Once received, the data is stored locally in memory elements, circuits, or devices, 

such as RAM. or flash memory, including external storage devices, for playback. 
Depending on the amount of data and the image resolution, the playback might begin 
relatively quickly, or be presented with longer-term delay. That is, in some instances, 
image presentation allows for a certain degree of real time playback for very small or low 
resolution images not requiring, much data, or using some type of buffering, so that after . a 
small delay, some material is presented while more material is being transferred. Provided 
there are no interruptions in the transfer link, once the presentation begin? the transfer is 
reasonably transparent to the end user of the viewing device. 
[0006] The data used to create either still images or motion video are often compressed 

using one of several well known techniques such as those specified by the Joint 
Photographic Experts Group (JPEG), the Motion Picture Experts Group (MPEG), and other 
well known standards organizations or companies in the media, computer, and 
communications industries to speed the transfer of data over a communication link. This 
allows transferring images or data faster by using a smaller number of bits to transfer a 
given amount of information. 
[0007] Once the data is transferred to a "local" device such as a computer or other recipient 

device, the resulting information is un-compressed (or played using special decoding 
players), and decoded if needed, and prepared for appropriate presentation based on the 
corresponding available presentation resolution and control elements. For example, a 
typical computer video resolution in terms of a screen resolution of X by Y pixels- typically 
ranges from as low as 4.80x640 pixels, through 600x800 to 1024x1024, although a variety 
of other resolutions are generally possible, either as desired or needed. 
[0008] Image presentation is also affected by the image content and the ability of given 

video controllers: to manipulate the image in terms of certain predefined color levels or 
color depth (bits per pixel used to generate colors) and intensities, and any additional 



WO 2005/018191 



PC17US2004/026264 



3 

overhead bits being employed. For example, a typical computer presentation would 
anticipate anywhere from around 8 to 32, or more, bits per pixel to represent various colors 
(shades and hues), although other values are encountered. 
[0009] From the above values, one can see that a given screen image is going to require the 

transfer of anywhere from 2.45 Megabits (Mb) to around 33.55 Mb of data over the range 
from the lowest to highest typical resolutions and depth, respectively. When viewing video 
or motion type images at a rate of 30 frames per second, the amount of data required is 
around 73.7 to 1,006 Megabits of data per second (Mbps), or around 9.21 to 125.75 
Megabytes per second (MBps). In addition, one may desire to present audio data in 
conjunction with images, such as for a multimedia presentation, or as a separate high 
resolution audio presentation, such as CD quality music. Additional signals dealing with 
interactive commands, controls, or signals may also be employed. Each of these options 
adding even more data to be transferred. In any case, when one desires to transfer high 
quality or high resolution image data and high quality audio information or data signals to 
an end user to create a content rich experience, a high data transfer rate link is required 
between presentation elements and the source or host device that is configured to provide 
such types of data. 

[0010] Data rates of around 115 Kilobytes (KBps) or 920 Kilobits per second. (Kbps) can be 

routinely handled by modern serial interfaces. Other interfaces such as USB serial 
interfaces, can accommodate data transfers at rates as high as 12 MBps., and specialized 
high speed transfers such as those configured using the Institute of Electrical and 
Electronics Engineers (IEEE) 1394 standard, can occur at rates on the order of 100 to 400 
MBps. Unfortunately, these rates fall short of the desired high data rates discussed above 
which are contemplated for use with future wireless data devices and services for providing 
high resolution, content rich, output signals for driving portable video displays or audio 
devices. In addition, these interfaces require the use of a significant amount of host or 
system and client software to operate. Their software protocol stacks also create an 
undesirably large amount of overhead, especially where mobile wireless devices or 
telephone applications are contemplated. Such devices have severe memory and power 
consumption limitations, as well as already taxed computational capacity. Furthermore, 
some of these interfaces utilize bulky cables which are too heavy and unsatisfactory for 
highly aesthetic oriented mobile applications, complex connectors which add cost, or 
simply consume too much power. 
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[0011] There axe- other known interfaces such as the Analog Video Graphics Adapter 

(VGA), Digital Video Interactive (DVT) or Gigabit Video Interface (GV3F) interfaces. The 
first two of these are parallel type interfaces which process data at higher transfer rates, but 
also employ heavy cables and consume large amounts of power, on the order of several 
watts. Neither of these characteristics are amenable to use with portable consumer 
electronic devices. Even the third interface consumes too much power and uses expensive 
or bulky connectors. 

[0012] For some of the above interfaces-, and other very high rate data systems/protocols or 

transfer mechanisms associated with data transfers for fixed installation computer 
equipment, there is another major drawback. To accommodate the desired data transfer 
rates also requires substantial amounts of power and/or operation at high current levels. 
This greatly reduces the usefulness of such techniques for highly mobile consumer oriented 
products. 

[0013] Generally, to accommodate such data transfer rates using alternatives such as say 

optical fiber type connections and transfer elements, also requires a number of additional 
converters and elements that introduce much more complexity and cost, than desired for a 
truly commercial consumer oriented product. Aside from the generally expensive nature of 
optical systems as yet, their power requirements and complexity prevents general use for 
lightweight, low power, portable applications. 

[0014] What has been lacking in the industry for portable, wireless, or mobile applications, 

is a technique to provide a high quality presentation experience, whether it be audio, video, 
Or multimedia based, for highly mobile end users. That is, when using portable computers, 
wireless phones, PDAs, or other highly mobile communication devices or equipment, the 
current video and audio presentation systems or devices being used simply cannot deliver 
output at the desired high quality leveL Often, the perceived -quality that is lacking is the 
result of unobtainable high data rates needed to transfer the high quality presentation data. 
This can include both transfer to more efficient, advanced or feature laden external devices 
for presentation to an end user, or transfer between hosts and clients internal to portable 
devices such as computers, gaming machines, and wireless devices such as mobile 
telephones. 

10015] ■ In this latter case, there have been great strides made in adding higher and. higher 
resolution internal video screens*- and other specialty input and/or output devices and 
connections to wireless devices like so called "third generation telephones, and to so called 
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laptop computers. However, internal data bosses and connections which may include 
bridging across rotating or sliding hinge or hinge-like structures which mount or connect 
video screens or other elements to the main housing where the host and/or various other 
control elements and output components- reside. It is very difficult to construct high 
throughput data transfers interfaces using prior techniques which can require up to 90 
conductors to achieve the desired throughput, on say a wireless telephone, as- one example. 
This presents many manufactuiing, cost prohibitive, and reliability challenging issues to 
overcome. 

[0016] Therefore, a new transfer mechanism is needed to increase data throughput between 

host devices providing the data and client display devices or elements presenting an output 
to end users. 

[0017] Applicants have proposed such new transfer mechanisms in US Patent. Application 

Serial Nos. 10/020.520 and 10/236,657, both entitled "Generating And Implementing A 
Communication Protocol And Interface For High Data Rate Signal Transfer", now allowed, 
which are assigned to the assignee of the present invention and incorporated herein by 
reference. The techniques discussed in those applications can greatly improve the transfer 
rate for large quantities of data in high speed data signals. However, the demands for ever 
increasing data rates, especially as related to video presentations, continue to grow, Even 
with other ongoing developments in data signal technology, there is still a need to strive for 
even faster mm'Ccx t i - improved -oimi.au link efficiencies, and more powerful 
communication links. Therefore, there is a continuing need to develop a new or improved 
transfer mechanism which is needed to increase data throughput between host and client 
devices. 

SUMMARY 

[0018] The above drawback, and others, existent in the art aire addressed by embodiments 

of the invention in which a new protocol and data transfer means, method and mechanism 
have been developed for transferring data between a host device and a recipient client 
device at high data rates. 

[0019] Embodiments for (lie invention are directed to a Mobile Data Digital Interface 

(MDDD for transferring digital data at a high rate between a host device and a client device 
over a communication path which employs a plurality or series of packet structures linked 
together to form a communication protocol for communicating a pre-selected set of digital 
control and presentation .data between the host and client devices. The signal 
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coimauuications protocol or link layer is used by a physical layer of host or client link 
controllers. At least one link controller residing in the host device is coupled to the client 
device through the eommtmications path or link, and is configured to generate, transmit, 
and receive packets forming the coramunicaQons protocol, and to form digital presentation 
data into one or more types of data packets. The interface provides for bi-directional 
transfer of information between the host and client, which can reside within a common 
overall housing or support structure. 
[0020] The implementation is generally all digital in nature with the exception of 

differential drivers and receivers which can be easily implemented on a digital CMOS chip, 
requires a few as 6 signals, and operates at almost any data rate that is convenient for the 
system designer. The simple physical and link layer protocol makes it easy to integrate, and 
this simplicity plus a hibernation state enables the portable system to have very low system 
power consumption. 

[0021] To aid in use and acceptance, the interface will add very little to the cost of a device, 

will allow for consumption of very little power while able to power displays through the 
interface using standard battery voltages, and can accommodate devices having a pocket- 
able form-factor. The interface is scalable to support resolutions beyond HDTV, supports 
simultaneous stereo video and 7.1 audio to a display device, performs conditional updates 
to any screen region, and supports multiple datatypes in both directions. 

[0022] In further aspects of embodiments of the invention, at least one client link controller, 

or client receiver, is disposed in the client device and is coupled to the host device through 
the communications path or link. The client link controller is also configured to generate, 
transmit, and receive packets forming the communications protocol, and to form digital 
presentation data into one or more types of data packets. Generally, the host or link 
controller employs a state machine for processing data packets used in commands or certain 
types of signal preparation and inquiry processing, but can use a slower general purpose- 
processor to manipulate data and some of the less complex packets used in the 
communication protocol. The host controller comprises one or more differential line 
drivers; while the client receiver comprises one or more differential line receivers coupled 
to the communication path. 

[0023] The packets are grouped together within media frames; that are communicated 

between the host and client devices having a pre-defined fixed length with a pre-determined 
number of packets having different variable lengths. The packets each comprise a packet 
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length field,, one of more packet data fields, and a cyclic redundancy check field. A Sub- 
frame Header Packet is transferred or positioned at the beginning of transfers of other 
packets from the host, link controller. One or more Video Stream type packets and Audio 
Stream type packets ace used by the communications protocol to transfer video type data 
and audio type data, respectively, from the host to the client over a forward link for 
presentation to a client device user. One or more Reverse Link Encapsulation type packets 
are used by the communications protocol to transfer data from the client device to the host 
link controller. These transfer in some embodiments include the transfer of data from 
inlerral jcntrollers having at leas one MDDI device to internal video screens. Other 
embodiments include transfer to internal sound systems, and transfers from various input 
devices including joysticks and complex keyboards to internal host devices, 
[0024] Filler type packets are generated by the host link controller to occupy periods of 

forward link transmission that do not have data. A plurality of other packets are used by the 
communications protocol to transfer video information. Such packets include Color Map, 
Bit Block Transfer, Bitmap Area Fill, Bitmap Pattern Fill, and Transparent Color Enable 
type packets. User-Defined Stream, type packets are used by the communications protocol 
to transfer interface-user defined data. Keyboard Data and Pointing Device Data type 
packets are used by the communications protocol to transfer data to or from user input 
devices associated with said client device. A Link Shutdown type packet is used by the 
communications protocol to terminate the transfer of data in either direction over said 
communication path. 

[0025] The communication path generally comprises or employs a cable having a series of 

four or more conductors and a shield. In addition, printed wires or conductors can be used, 
as desired, with some residing on flexible substrates. 

[0026] The host link controller requests display capabilities information from the client 

device in order to determine what type of data and data rates said client is capable of 
accommodating through said interface. The client link controller communicates display or 
presentation capabilities to the host link controller using at least one Display Capability 
type packet. Multiple transfer modes are used by the communications protocol with each 
allowing the transfer of different maximum numbers of bits of data in parallel over a given 
time period, with each mode selectable by negotiation between the host and client link 
controllers. These transfer modes are dynamically adjustable during transfer of data, and 
the same mode need not be used on the reverse link as is used on the forward link. 
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[0027] la other aspects of some embodiments of the invention, the host device comprises a 

wireless communications device, such as a wireless telephone, a wireless PDA, or a 
portable computer having a wireless modem disposed therein. A typical client device 
comprises a portable video display such as a micro-display device, and/or a portable audio 
presentation system. Furthermore,, the host may use storage means or elements to store 
presentation or multimedia data to be transferred to be presented to a client device user. 

[0028] In still other aspects of some embodiments, the host device comprises a controller or 

communication link control device with drivers as described below residing within a 
portable electronic device such as a wireless communications device, such as a wireless 
telephone, a wireless PDA, or a portable computer. A typical client device in this 
configuration comprises a client circuit or integrated circuit or module coupled to the host 
and residing ihtin the same device, and to an internal video display such as a high resolution 
screen for a mobile phone, and/or a portable audio presentation system, 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0029] Further features and advantages of the invention, as well as the structure and 

operation of various embodiments of the invention, are described in detail below with 
reference to the accompanying drawings. In the drawings, like reference numbers generally 
indicate identical, functionally similar, and/or structurally similar elements or processing 
steps, and the drawing in Which an element first appears is indicated by the leftmost digit(s) 
in the reference number. 

[0030] FIG, 1A illustrates a basic environment in which embodiments of the invention 

might operate including the use of a micro-display device used in conjunction with a 
portable computer. 

[0031] FIG. IB illustrates a basic environment in which embodiments of the invention 

might operate including the use of a micro-display device and audio presentation elements 

used in conjunction with a wireless transceiver. 
[0032] FIG. 1C illustrates a basic environment in which embodiments of the invention 

might operate including the use of .a rnicro-display device used in conjunction with a 

portable computer. 

[0033] FIG. ID illustrates a basic environment in which embodiments of the invention 

might operate including the use of a micro-display device and. audio presentation elements 
used in conjunction with a wireless transceiver. 
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[0034] HQ, 2 i llustrates the overall concept of a Mobile Digital Data Interface with a host 

and client interconnection, 
[Q035] FIG. 3 illustrates the structure of a packet useful for realizing data transfers from a 

client device to a host device. 
[0036] FIG, 4 illustrates the use of an MDDI link controller and the types of signals passed 

between a host and a client over the physical data link conductors for Type I and Type U 

interfaces. 

[0037] FIG. 5 illustrates the use of an MDDI link controller and the types of signals passed 

between a host and a client over the physical data link conductors for Types II, II, and IV 

interfaces. 

[0038] FIG. 6 illustrates the structure of frames and sub-frames used to implement the 

interface protocol. 

[0039] FIG. 7 illustrates the general structure of packets used to implement the interface 

protocol. 

[0040] FIG. S illustrates the format of a Sub-frame Header Packet. 

[0041] FIG. 9 illustrates the format and contents of a Filler Packet, 

[0042] FIG. 10 illustrates the format of a Video Stream Packet. 

[0043], FIG. 11 illustrates the format and contents for the Video Data Format Descriptor of 

FIG, 10. 

[0044] FIG. 12 illustrates the use of packed and unpacked formats for data. 

[0045] FIG, 13 illustrates the format of an Audio Stream Packet. 

[0046] fig. 14 illustrates lite use of byte-aligned and packed PCM formats for data 

[0047] FIG. 1 5 illustrates the format of a User-Defined Stream Packet. 

[0048] FIG. 16 illustrates the format of a Color Map Packet, 

[0049] FIG. 17 illustrates the format of a Reverse Link Encapsulation Packet. 

[0050] FIG. 18 illustrates the format of a Display Capability Packet. 

[0051] FIG. 19 illustrates the format of a Keyboard-Data Packet. 

[0052] FIG, 20 illustrates the format of a Pointing Device Data Packet. 

[005 3] FIG, 2 1 illustrates the format of a Link Shutdown Packet. 

[0034] FIG. 22 illustrates the format of a Display .Request and Status Packet. 

[0055] FIG. 23 illustrates the format of a Bit Block Transfer Packet. 

[0056] FIG. 24 illustrates the format of a Bitmap Area Fill Packet. 

[0057] FIG. 25 illustrates the format of a Bitmap Pattern Fill Packet. 
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[0058] FIG. 26 illustrates the format of a Communication Link Data Channel Packet. 

[0059] FIG, 27 illustrates the format of a Interface Type Ftandoff Request Packet. 

[0060] FIG. 28 illustrates the format of an Interface Type Acknowledge Packet. 

[0061] FIG. 29 illustrates the format of a Perform Type Handoff Packet. 

[0062] FIG. 30 illustrates the format of a Forward Audio Channel Enable Packet. 

[0063] pjG, 3 1 illustrates the format of a Reverse Audio Sample Rate Packet. 

[0064] FIG. 32 illustrates the format of a Digital Content Protection Overhead Packet. 

[0065] FIG. 33 illustrates the format of a Transparent Color Enable Packet. 

[0066] FIG. 34 illustrates the format of a Round Trip Delay Measurement Packet. 

[0067] FIG. 35 illustrates the timing of events during the Round Tnp Delay Measurement 
Packet. 

[0068] FIG. 36 illustrates a sample implement 



f a CRC generator and checker useful 



for implementing the invention. 
[0069] FIG. 37A illustrates the timing of CRC signals for the apparatus of FIG. 36 when 

sending data packets, 

[0070] FIG, 37B illustrates the timing of CRC signals for the apparatus of FIG. 36 when 

receiving data packets, 

[0071] FIG. 38 illustrates processing steps for a typical service request with no contention. 

[0072] FIG. 39 illustrates processing steps for a typical service request asserted after the 

link restart sequence has begun, contending with link start. 
[0073]: FIG. 40 illustrates how a data sequence can be transmitted using DATA-STB 

encoding, 

[0074] FIG. 41 illustrates circuitry useful for generating the DATA and STB signals from 

input data at the host, and then recovering the data at the client. 
[0075] FIG. 42 illustrates drivers and terminating resistors useful for implementing one 

embodiment. 

[0076] FIG. 43 illustrates steps and signal levels employed by a client to secure service 

from the host and by the host to provide such service. 
[0077] FIG. 44 illustrates relative spacing between transitions on the DataO, other data lines 

(DataX), and the strobe lines (Stb). 
[0078] FIG. 45. illustrates the presence- of a delay in response that can occur when a host 

disables the host driver after transferring a packet. 
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[0079] FIG. 46 illustrates the presence of a delay in response that pan occur when a host 

enables the host dri ver to transfer a packet. 

[0080] FIG. 47 illustrates the relationship at the host receiver input between the timing of 

the data being transferred and the leading and trailing edges of the strobe pulses. 

[0081] FIG. 48 illustrates switching characteristics and corresponding client output delay- 

developed by the reverse data timing. 

[0082] FIG. 49 illustrates a high level diagram of signal processing steps and conditions by 

which synchronization can be implemented using a state machine. 

[0083] FIG. 50 illustrates typical amounts of delay encountered for signal processing on the 

forward and reverse paths in a system employing the MD.DL 

[0084] FIG. 5 1 illustrates marginal round trip delay measurement. 

[0083] FIG. 52 illustrates Reverse Link data rate changes. 

[0086] FIG. 53 illustrates a graphical representation of values of the Reverse Rate Divisor 

versus forward link data rate. 
[0087] FIGS . 54 A and 54B illustrate steps undertaken in the operation of an interface. 

[0088] FIG. 55 illustrates an overview of the interface apparatus processing packets. 

[0089] FIG. 56 illustrates the format of a Forward Link Packet 

[0090] FIG. 57 illustrates typical values for propagation delay and skew in an Type-I Link 

interface. 

[0091] FIG. 58 illustrates Data, Stb, and Clock Recovery Timing on a Type-I Link for 

exemplary signal processing through the interface. 
[0092] FIG. 59 illustrates typical values for propagation delay and skew in Type-II, Type- 

in or Typc-IV Link interfaces. 
[0093] FIGS. 60 A. 60B, and 60C illustrate different possibilities for the timing of two data 

signals and MDDIJStb with respect to each other, being ideal, early, and. late, respectively. 
[0094] FIG. 61 illustrates interface pin assignments exemplary connectors used with a 

Type-I/Type-n interfaces. 
[0095] FIGS. 62A and 62B illustrate possible MDDIJData and MDDI.Stb waveforms for 

both Type-I and Type-II Interfaces, respectively. 
[0096] FIG. 63 illustrates a high level diagram of alternative signal processing steps and 

conditions by which synchronization can be implemented using a state machine. 
[0097] FIG. 64 illustrates exemplary relative timing between a series of clock cycles and 

the timing of a various reverse link packets- bits and divisor values. 
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(00981 FIG. 65 illustrates exemplary error code transfer processing, 

[0099] FIG. 66 illustrates apparatus useful for error code transfer processing. 

[00100] FIG. 67A illustrates error code transfer processing for code overloading. 

("00 10 1] FIG. 67B illustrates error code transfer processing for code reception. 

[00102] FIG. 6SA illustrates processing steps for a host initiated wake-up. 

[0D103] PIG, 68B illustrates processing steps for a client initiated wake-up. 

[00104] FIG, 6SC illustrates processing steps for host and client initiated wake-up with 
contention. 

[00 1 05] FIG. 69 illustrates the format of a Request VCP Feature Packet 

[00 1.06] FIG. 70 illustrates the formal of a YCP Feature Reply Packet 

[00107] FIG. 71 illustrates the format of a VCP Feature Reply List 

[00108] FIG. 72 illustrates the format of a Set VCP Feature Packet 

[00109] FIG. 73 illustrates the format of a Request Valid Parameter Packet 

[001 10] FIG. 74 illustrates the format of a Valid Parameter Reply Packet 

[00 1 1 i] FIG. 75 illustrates the format of a Alpha-Cursor Image Capability Packet 

[00 1 12] FIG. 76 illustrates the format of a Alpha-Cursor Transparency Map Packet 

[001 1 3] FIG. 77 illustrates the format of a Alpha-Cursor Image Offset Packet 

[001 14] FIG. 78 illustrates the format of a Alpha-Cursor Video Stream Packet 

[00115] FIG. 79 illustrates the format of a Scaled Video Stream Capability Packet 

[001 16] FIG. 80 illustrates the format of a Scaled Video Stream Setup Packet 

[001 17] FIG. S 1 illustrates the format of a Scaled Video Stream Acknowledgement Packet 

[001 IS] FIG; 82 illustrates the format of a Scaled Video Stream Packet 

[00 1 19] FIG. 83 illustrates the format of a Request Specific Status Packet 

[00120] FIG, 84 illustrates the format of a Valid Status Reply List Packet 

[00121] FIG. 85 illustrates the format of 'a Packet Processing' Delay Parameters Packet 

(00122] FIG. 86 illustrates the format of a Personal Display Capability Packet 

[00123] FIG. 87 illustrates' the format of a Display Error Report Packet 

[00124] FIG. 88 illustrates the format of a Display Identification Packet 

[00125] FIG. 89 illustrates the format of a Alternate Display Capability Packet 

[00126] FIG, 90 illustrates the format of: a Register Access Packet 

[00127] FIG. 91 A-91C illustrate use of two-display buffers to reduce visible artifacts" 

[00128] FIG. 92 illustrates two buffers with display refresh faster than, image transfer" 

[00129] FIG. 93 illustrates two buffers with display refresh slower than image transfer" 
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[001 30] FIG. 94 illustrates two buffers with display refresh much faster than image transfer" 

[00131] FIG. 95 illustrates three buffers with display refresh faster than image transfer" 

[00132] FIG. 96 illustrates three buffers with display refresh slower than image transfer" 

[001 33] FIG. 97 illustrates one buffer with display refresh faster than image transfer" 
[00134] FIG. 98 illustrates host client connection via daisy -chain and hub. 

[00135] FIG. 99- illustrates client de-vices connected via a combination of hubs and daisy 

chains. 



DETAILED DESCRIPTION OF THE EMBODIMENTS 
I. Overview 

[00136] A general intent of the invention is to provide a Mobile Display Digital Interface 

(MDDI), as discussed below, which, results, in or provides a cost-effective, low power 
consumption, transfer mechanism that enables high- or very-high- Speed data transfer over a 
short-range communication link between a host device and a client device, such as a display 
element, using a "serial" type of data link or channel. This mechanism lends itself to 
implementation with miniature connectors and thin flexible cables which are especially 
useful in connecting internal (to a housing or support frame) display elements or input 
devices to a central controller, or external display elements or devices such as wearable 
micro-displays (goggles or projectors) to portable computers, wireless communication 
devices, or entertainment devices. 

[00137] An advantage of embodiments of the invention is that a technique is provided for 

data transfer that is low in complexity, low cost, has high reliability, fits well within the 
environment of use, and is very robust, while remaining very flexible. 

[00138] Embodiments of the invention can be used in a variety of situations to communicate 

or transfer large quantities of data, generally for audio, video, or multimedia applications 
from a host or source device where such data is generated or stored, to a client display or 
presentation device at a high rate. A typical application, which is discussed below, is the 
transfer of data from either a portable computer or a wireless telephone or modem to a 
visual display device such as .a -small video screen or a wearable micro-display appliance, 
such as in the form of goggles or helmets containing small projection lenses and screens, or 
from a host to client device within such components. That is, from a processor to an 
internal screen or other presentation element, as well as from various internal, or external 
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input devices employing a client to an internally located (collocated within same device 
housing or support structure) host. 

[00139] The characteristics or attributes of the MODI are such that they are independent of 

specific display technology. This is a highly flexible mechanism for transferring data at a 
high rate without regards to the internal structure of that data, nor the functional aspects of 
the data or commands it implements. This allows the timing of data packets being 
transferred to be adjusted to adapt to the idiosyncrasies of particular client devices, such as 
for unique display desires for certain devices, or to meet the requirements of combined 
audio and video for some A-V systems, or for certain input devices such as. joysticks, touch 
pads, and so forth. The interface is very display element or client device agnostic, as long 
as the selected protocol is followed. In addition, the aggregate serial link data or data rate 
can vary over several orders of magnitude which allows a communication system or host 
device designer to optimize the cost, power requirements, client device complexity, and 
client device update rates. 

[00140] The data interface is presented primarily for use in transferring large amounts of 
high rate data over a "wired" signal link or small cable. However, some applications may 
take advantage of a wireless link as well, including optical based links, provided it is 
configured to use the same packet and data structures developed for the interface protocol, 
and can sustain the desired level of transfer at low enough power consumption or 
complexity to remain practical. 

II. Environment 

[00141] A typical application can be seen in FIGS. I A and IB where a portable or laptop 

computer .100 and wireless telephone or PDA device 102 are shown communicating data 
with display devices 104 and 106, respectively, along with audio reproduction systems 108 
and 112, In addition, FIG 1A shows potential connections to a larger display or screen 114 
or an image projector 116, which are only shown in one figure for clarity, but are 
connectable to wireless device 102 as well. The wireless device can be currently receiving 
data or have previously stored a certain amount of multimedia type data in a memory 
element or device for later presentation for viewing and/or hearing by an end user of the 
wireless device. Since a typical wireless device is used for voice and simple text 
communications most of the time, it has a rather small display screen and simple audio 
system (speakers) for communicating information to the device 1.Q2 user. 
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[00142] Computer 100 has a much larger screen, "but still inadequate external sound system, 

and still falls short of other multimedia presentation devices such as a high definition 
television, or movie screens. Computer 100 is used for purposes of illustration and other 
types of processors, interactive video games, or consumer electronics devices can also be 
used with the invention. Computer 100 can employ,, but is not limited to or by, a wireless 
modem or other built in device for wireless communications, or be connected to such 
devices using a cable or wireless link, as desired. 

[00143] This makes presentation of more complex or "rich" data a less than a useful or 

enjoyable experience. Therefore, the industry is developing other mechanisms and devices 
to present the information to end users and provide a minimum level of desired enjoyment 
or positive experience, 

[00144] As previously discussed above, several types of display devices have or are 

currently being developed for presenting information to end users of device 100. For 
example, one or more companies have developed sets of wearable goggles that project an 
image in front of the eyes of a device user to present a visual, display. When correctly 
positioned, such devices effectively "project" a virtual image, as perceived by a users eyes, 
that is much larger than the element providing the visual output. That is, a very small 
projection element allows the eye(s) of the user to "see" images on a much larger scale than 
possible with typical LCD screens and the like. The use of larger virtual screen images also 
allows the use of much higher resolution images than possible with snore limited LCD 
screen displays. Other display devices could include, but are not limited to, small LCD 
screens or various flat panel display elements, projection lenses and display drivers for 
projecting images on a surface, and so forth. 
[00145] There may also be additional elements connected to or associated with the use of 

wireless device 102 or computer 100 for presenting an output to another user, or to another 
device which, in turn .transfers the signals elsewhere or stores them. For example, data may 
be stored in flash memory, in optical form, for example using a writeable CD media or on 
magnetic media such as in a magnetic tape recorder and similar devices, for later use. 
[00146] In addition, many wireless devices and computers now have built-in MP3 music- 
decoding capabilities, as well as other advanced sound decoders and systems. Portable 
computers utilize CD and DVD playback" capabilities as a general rale, and some have 
small dedicated flash memory readers for receiving pre-recorded audio files. The issue with 
having such capabilities is that digital music files promise a highly increased feature rich 
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experience, but only if the decoding and playback process can keep pace. The same holds 
true for the digital video files. 
[00147] To assist with sound .reproduction, external speakers 114 are shown; in FIG. la, 

which could also be accompanied by addition elements such as sub-woofers, or "surround- 
sound." speakers for front and rear sound projection. At the same time, speakers or 
earphones 108 are indicated as built-in to the support frame or mechanism of micro-display 
device 106 of FIG. lb. As would be known, other audio or sound reproduction elements 
can be used including power amplification or sound shaping devices. 
[00148] In any case, as discussed above, when one desires to transfer high quality or high 

resolution image data and high quality audio information or data signals from a data source 
to an end user over one or more communication links 1 10, a high data rate is required. That 
is. transfer link 110 is clearly a potential bottleneck in the communication of data as 
discussed earlier, and is limiting system performance, since current transfer mechanisms do 
not achieve the. high data rates typically desired. As discussed above for example, for 
higher image resolutions such as 1024 by 1024 pixels, with color depths of 24-32 bits per 
pixel and at data rates of 30 fps, the data rates can approach rates in excess of 755 Mbps or 
more. In addition, such images may be presented as part of a multimedia presentation 
which includes audio data and potentially additional signals dealing with interactive gaming 
or communications, or various commands, controls, or signals, farther increasing the 
quantity or data and the data rate. 
[00149] It is also clear that fewer cables or interconnections required for establishing a data 

link, means that mobile devices associated with a display are easier to use, and more likely 
to be adopted by a larger user base. This is especially true where multiple devices are 
commonly used to establish a full audio-visual experience, and more especially as the 
quality level of the displays and audio output devices increases. 
[00150] Another typical application related to many of the above and other improvements in 

video screens and other output or input devices can be seen in FIGS. 1C and ID where a 
portable or laptop computer 130 and wireless telephone or PDA device 140- are shown 
communicating data with "internal" display devices 134 and 144, respectively, along with 
audio reproduction systems 136 and 146. 
[00151] In FIGS . 1C and ID, small cut-away sections of the overall electronic devices or 

products are used to show the location of one or more internal hosts and controllers in one 
portion of the device with a generalized communication link, here 138 and 148, 



WO 2005/018191 



PC17US2004/026264 



17 

respectively, connecting them to the video display elements or screens having the 
corresponding clients, across a rotating joint of some known type used throughout the 
electronics industry today. One can see that the amount of data involved in these transfers 
requires a large lurd^i of co da tors t< mprise links ^ a'lu 148 It is estimated that 
such communication links are approaching 90 or more conductors in order to satisfy today's 
growing needs for utilizing advanced color and graphical interfaces, display elements, on 
such devices because of the types of parallel or other known interface techniques available 
for transferring such data.. 

[00152] Unfortunately, die higher data rales exceed current technology available for 
transferring data. Both in tero» of the raw amount of data needing to be transferred per unit 
time, and in terms of manufacturing reliable cost, effective physical transfer mechanisms. 

[00153] What is needed is a technique for transferring data at higher rates for the data 
transfer link or communication path between presentation elements and the data source, 
which allows for consistently low(er) power, light weight, and as simple and economical a 
cabling structure as possible. Applicants have developed a new technique, or method and 
apparatus, to achieve these and other goals to allow an array of mobile, portable, or even 
fixed location devices to transfer data to desired displays, micro-displays, or audio transfer 
elements, at very high data rates, while maintaining a desired low power consumption, and 
complexity. . 

HI. High .Kate Digital Data Interface System Architecture 

[00154] In order to create and efficiently utilize a new device interface, a signal protocol and 

system architecture has been formulated that provides a very high data transfer rate using 
low power signals. The protocol is based on a packet and common frame structure, or 
structures linked together to form a protocol for communicating a pre-selected set of data or 
data types along with a command or operational structure imposed on the interface. 

A. Overview 

[00155] The devices connected by or communicating over the MDDT link are called the host 

and client, with the client typically being a display device of some type, although other 
output and input devices are. contemplated. Data from the host to the display travels in the 
forward direction (referred to as forward traffic or link), and data from the client to the host 
travels in the reverse direction (reverse traffic or link), as enabled by the host. This is 
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illustrated In the basic configuration shown in FIG. 1.- In FIG. 2, a host 202 is connected to 
a client 204 using a bi-directional communication channel 206 which is illustrated as 
comprising a forward link 208 and a reverse link 210. However, these channels are famed 
by a common set of conductors whose data transfer is effectively switched between the 
forward or reverse link operations. This allows for greatly reduced numbers of 
conductors, immediately addressing one of the many problems faced with current 
approaches to high speed data transfer in low power environment such as for mobile 
electronic devices. 

[00156] As discussed elsewhere, the host comprises one of several types of devices that can 

benefit from using the present invention. For example, host 202 could be a portable 
computer in the form of a handheld, laptop, or similar mobile computing device, it could be 
a Personal Data Assistant (PDA), a paging device, or one of many wireless telephones or 
modems. Alternatively, host 202 could be a portable entertainment or presentation device 
such as a portable DVD or CD player, or a game playing device. 

[00157] Furthermore, the host can reside as a host device or control element in a variety of 
other widely used or planned commercial products for which a high speed communication 
link is desired with a client. For example, a host could be used to transfer data at high rates 
from a video recording device to a storage based client for improved response, or to a high 
resolution larger screen for presentations. An appliance such as a refrigerator that 
incorporates an onboard inventory of computing system and/or Bluetooth connections to 
other household devices, can have improved display capabilities when operating in an 
internee or Bluetooth connected mode, or have reduced wiring needs for in-the-door 
displays (a client) and keypads or scanners (client) while the electronic computer or control 
systems (host) reside elsewhere in the cabinet. In general, those skilled in the art will 
appreciate the wide variety of modem electronic devices and appliances that may benefit 
from the use of this interface, as well as the ability to retrofit older devices with higher data 
rate transport of Information utilizing limited numbers of conductors available In connectors 
or cables, 

[00158] At the same time, client 204 could comprise a variety of devices useful for 

presenting information to an end user, or presenting information from a user to the host. 
For example, a micro-display incorporated in goggles or glasses, a projection device built 
into a hat or helmet, a small screen or even holographic element built into a vehicle, such as 
in a window or windshield, or various speaker, headphone, or sound systems for presenting 
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high quality sound or music. Another example would be the use of touch pads or sensitive 
devices, voice recognition input devices, security scanners and so forth that may want to 
transfer a significant amount of information from the user with little actual "input" other 
than touch or sound from the user. 

[00159] However, those skilled in the art will readily recognize that the present invention is 

not limited to these devices, there being many other devices on the -market, and proposed 
for use, that are intended to provide end users with high quality images and sound, either in 
terms of storage and transport or in terms of presentation at playback. The present 
invention is useful in increasing the data throughput between various elements or devices to 
accommodate the high data rates needed for realizing the desired user experience. 

[00160] The inventive MDD Interface and communication signal protocol may be used to 

simplify the interconnect between a host processor and a display within a device (internal 
mode) to reduce the cost of these connections and improve reliability, not just for external 
elements (external mode). The aggregate serial link data rate on each signal pair used by 
this interface structure can vary over many orders of magnitude, which allows a system or 
device designer to easily optimize cost, power, implementation complexity, and the display 
update rate. The attributes of MDDI are independent of display technology. The timing of 
data packets transferred through the interface can be easily adjusted to adapt to 
idiosyncrasies of particular display devices or combined timing requirements of audio-video 
systems. While this allows the system to have the smallest power consumption possible, it 
is not a requirement of the display to have a frame buffer in order to use MDDI. 



B. Interface Types 

[00161] The MDD Interface is contemplated as addressing five or more somewhat distinct 
physical types of interfaces found in the communications and computer industries. These 
are labeled simply -as Type-I, Type n. Type-Ill, Type-TV arid Type-U, although other labels 
or designations may be applied by those skilled in the art depending upon the application 
they are used for. 

[00162] The Type-I interface, is- configured as a 6-wire (conductor) interface which makes it 

suitable for mobile or wireless telephones, PDAs., e-Books, electronic games, and portable 
media players, such as CD players, or MP3 players, and similar- devices or devices used on 
similar types of electronic consumer technology. In one embodiment, a Type-U interface is 
configured as an S-wire (conductor) interface which is more suitable for laptop, notebook, 
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or desktop personal computers and similar devices or applications, that do not require the 
display to be updated rapidly and do not have a built-in MDDI link controller. This 
interface type is also distinguishable by the use of an additional two-wire Universal Serial 
Bus (USB) interface, which is extremely useful in accommodating existing operating 
systems or software support found on most personal computers. Type-U interfaces can also 
be used in a USB-only mode where the display simply has a USB connector that connects 
to a standard USB port on a computer or similar device, for example a consumer electronics 
device equipped with such a port, such as digital cameras or video players. 

[00163] Type-H, Type-IH, and Type-IV interfaces are suitable for high performance clients 

or devices and use larger more complex cabling with additional twisted-pair type 
conductors to provide the appropriate shielding and low loss transfers for data signals. 

[001641 The Type-I interface passes signals which can comprise display, audio, control, and 
limited signaling information, and is typically used for mobile clients or client devices that 
do not require high-resolution full-rate video data. A Typc-I interface can easily support 
SVGA resolution at 30 fp& plus 5.1 channel audio, and in a minimum configuration might 
use only three wire pairs total, two pairs for data transmission and one pair for power 
transfer. This type of interface is primarily intended for devices, such as mobile wireless 
devices, where a USB host is typically not available within the such device for connection 
and transfer of signals, in this configuration, the mobile wireless device is a MDDI host 
device, and acts as the "master" that controls the communication link from the host, which 
generally sends data to the client (forward traffic or link) for presentation, display or 
playback. 

[00165] In this interface, a host enables receipt of communication data at the host from the 

client (reverse traffic or link) by sending a special command or packet type to the client that 
allows it to take over the bus (link) for a specified duration and send data to the host as 
reverse packets. This- is illustrated in FIG. 3, where a type of packet referred to as an 
encapsulation packet {discussed below) is used to accommodate the transfer of reverse 
packets over the transfer link, , creating the reverse link. The time- interval allocated for the 
host to poll the client for data is pre-determined by the host, and is based on the 
requirements of each specified application. This type of half-duplex bi-directional data 
transfer is especially advantageous where a USB port is not available for transfer of 
information or data from the client. 
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[00166] High-performance displays? capable of HDTV type or similar high resolutions 
require around 1.5 Gbps rate data streams in order to support full-motion video. The Type- 
II interface supports high, data rates by transmitting 2 bits in parallel, the Type-DI by 
transmitting 4 bits in parallel, and the Type-IV interface transfers 8 bits in parallel, Type-II 
and Type-HI use the same cable and connector as Type-I but can operate at twice and four 
tiroes the data rate to support higher-performance video applications on portable devices. 
Type- IV is suited for very high performance clients or displays and requires a slightly 
larger cable that contains additional twisted-pair dam signals. 
[00167] The protocol used by the MDDI allows each Type-I,- II, -in, or -IV host to 

generally communicate with any Type-I, -II, -HI, or -IV client by negotiating what is the 
highest data rate possible that can be used'. The capabilities or available features of what 
can be referred to as the least capable device is used to set the performance of the link. As a 
rule, even for systems where the host and client are both capable using Type-II, Type-Ill, or 
Type-IV interfaces, both begin operation as a Type-I interface: The host then determines 
the capability of the target client, and negotiates a hand-off or reconfiguration operation to 
either Type-II, Type-ffl, or Type-IV mode, as appropriate for the particular application. 
[00168] It is generally possible for the host to use the proper link-layer protocol (discussed 
further below) and step down or again reconfigure operation at generally any time to a 
slower mode to save power or to step up to a faster mode to support higher speed transfers, 
such as for higher resolution display content. For example, a host may change interface 
types when the system switches from a power source such as a battery to AC power, or 
when the source of the display media switches to a lower or higher resolution format, or a 
combination of these or other conditions or events may be considered as a basis for 
changing an interface type, or transfer mode. 
[00169] It is also possible for a system to communicate data using one mode in one direction 

and another mode in another direction. For example, a Type TV interface mode could be 
used to transfer data to a display at a high, rate, while a Type I or Type U mode is used when 
transferring data to a host device from peripheral devices such as a keyboard or a pointing 
device. It will, he appreciated by .one skilled in the art that hosts and clients may 
communicate outgoing data at different rates.. 
[00170] Often, users of the MDDI protocol may distinguish between an "external" mode and 

an "internal" mode. An external mode describes the use of MDDI to connect .a host in one 
device to a client outside of that device that is up to about 2 meters from the host, hi this 
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situation, the host may also send power to the external client so that both devices can easily 
operate In a mobile environment. An internal mode describes when the host is. connected 
to a client contained inside the same device, such as within a common housing or support 
frame or structure of some kind. An example would be applications within a wireless 
phone or other wireless device, or a portable computer or gaming device where the client is 
a display or display driver and the host is a central controller, graphics engine, or CPU 
element. Since a client is located much closer to die host in internal mode applications as 
opposed to external mode applications, there are generally no requirements discussed for 
the power connection to the client in such configurations. 

C. Physical Interface Structure 

[00171] The general disposition of a device or link controller for establishing 

communications between host and client devices is shown in FIGS. 4 and 5. In FIGS. 4 and 
5, a MDDI link controller 402 and 502 is shown installed in a host device 202 and a MDDI 
link controller 404 and 504 is shown installed in. a client device 204. As before, host 202 is 
connected to a client 204 using a bi-directional communication channel 406 comprising a 
series of conductors. As discussed below:, both the host and client link controllers can be 
manufactured as an integrated circuit using a single circuit design that can be set, adjusted 
or programmed to respond as either a host controller (driver) or a client controller 
(receiver). This provides for lower costs due to larger scale manufacturing of a single 
circuit device. 

[00172] In FIG. 5, a MDDI link controller 502 is shown installed in a host device 202' and a 

MDDI link controller 504 is shown installed in a client device 204'. As before, host 202' is 
connected to a client 204' using a bi-directional communication channel 506 comprising a 
series of conductors. As discussed before, both the host and client link controllers can be 
manufactured using a single circuit design. 

[00173] Signals passed between a host and a client, such as a display device, over the MDDI 

link, or the physical conductors used, are also illustrated in FIGS. 4 and 5. As seen in 
FIGS. 4 and 5, the primary path or mechanism for transferring data through the MDDI uses 
data signals labeled as MDDI_Data0+/- and MDDI_Stb+/-. Each of these are low voltage 
data signals that are transferred over a differential pair of wires in a cable. There is only 
one transition on cither the MDDI_DataO pair or the MDDI_Stb pair for each bit. sent over 
the binterface. This is a voltage based transfer mechanism, not current based, so static 
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current consumption is near zero. The host drives the MDDI_Stb signals to the client 
display. 

[00174] While data can flow in both the forward and reverse directions over the MDDIJData 

pairs, that is, it is a bi-directional transfer path, the host is the master or controller of the 
data link. The MDDlJDataO and MDDI-Stb signal paths are operated in a differential mode 
to maximize noise immunity. The data rate for signals on these lines is determined by the 
rate of the clock sent by the host, and is variable over a range of about 1 kbps up to 400 
Mbps or more. 

[00175] The Type-TI interface contains one additional data pair or conductors, or paths 

beyond that of the Type-I, referred to as MDDI_Datal+/-. The Type-Ill interface contains 
two additional data pairs or signal paths beyond that of the Type-H interface referred to as 
MDDLPata2+/~, and MDDIJ3ata3+/-. The Type-W interface contains four more data 
pairs or signal paths beyond that of the Type-HI interface referred to as: MDDI_data4+A, 
MDDI_Data5+/-, MPPI_Data6+/-, and MDDI_Data7+/-, respectively. In each of the 
above interface configurations, a host can send power to the client or display using the wire- 
pair or signals designated as MDDI_Pwr and MDDIj3nd. As discussed further below, 
power transfer can also be accommodated, if desired, in some configurations on the 
MDDI_data4+/-, MDDI_Data5+/-, MDDI_Data6+/- t or MDDI_Data7+/- conductors when 
an interface "Type" is being used that employs fewer conductors than are available or 
present for the other modes. 

[00176] A summary of the signals passed between the host and client (display) over the 

MDDI link: for various modes are illustrated in Table I, below, in accordance with the 
interface type. 

Table I 





Type-H 






MDDLPwr/Gnd 


MDDLPwr/Gnd 


MDDI_Pwr/Gnd 


MDDLPwr/Gnd 


MDDI_Sth+/- 


MDDIStb+/- 


MDDI_Stb+/- 


MD.DI_Stb+/- 


MDDLDataQ+/- 


MDDI_DataO+/- 


MDDIJData0+/- 


MDDLData0+/~ 




MDDI„Datal+/» 


MDDIJDatat-f/- 


MDDLDatal+/- 






MDDT_Data2+/- 


MDDI„Data2+/- 






MDDI_Data3+/- 


MDDUData3+/- 


Optional Pwr 


Optional Pwr 


Optional Pwr 


MDDI_Data4+/- 


Optional Pwr 


Optional Pwr 


Optional Pwr 


MDDI_Data3+/- 


Optional Pwr 


Optional Pwr 


Optional Pwr 


MDDIJ3ata6+/- 


Optional Pwr 


Optional Pwt 


Optional Pwr 


MDDI„Data7+/- 
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[00177] Also note that the MDDI Pwr/Gnd connections for transfer from the host are 

provided generally for external .modes. Internal applications or modes of operation 
generally have clients that draw power directly from other internal resources, and do not use 
MDDI to control power distribution, as would be apparent to one skilled in the art, so such 
distribution is not discussed in further detail here. However, it is certainly possible to allow 
power to be distributed through the MDDI interface to allow for certain kinds of power 
control, synchronization, or interconnection convenience, for example, as would be 
understood by one skilled in the art. 

[001781 Cabling generally used to implement the above structure and operation is nominally 

on the order of 1.5 meters in length, generally 2 meters or less, and contains three twisted 
pairs of conductors, each in turn being multi-strand 30 AWG wire. A foil shield covering is 
wrapped or otherwise formed above the three twisted pairs, as an additional drain wire. The 
twisted pairs and shield drain conductor terminate in the display connector with the shield 
connected to the shield for the display (client), and there is an insulating layer, covering die 
entire cable, as would be well known in the art. The wires are paired as: MBD.L,Gnd with 
MDDIPwr; MDDI_Stb+ with MDDI.SW-; MDDJ_Data0+- with MDDIJDataO-: 
MDDI_X»atal+ withMDDLDatals and so forth. 

IX Data Types and Rates 
[00179] To achieve a useful interface for a full range of user experiences and applications, 
the Mobile Digital Data Interface (MDDI) provides support for a variety of clients and 
display information, audio transducers, keyboards, pointing devices, and many other input 
or output devices that, might be integrated into or working in concert with a mobile display 
device, along with control information, and combinations thereof. The MDD -interface is 
designed to be able to accommodate a variety of potential types of streams of data 
traversing between the host and client in either the forward or reverse link directions using a 
minimum number of cables or conductors. Both isochronous streams and asynchronous 
stream (updates) are supported. Many combinations of data types are possible as long as 
the aggregate data rate is less than or equal to the maximum desired MDDI link- rate, which 
is limited by the maximum serial rate and number of data airs employed. These could 
include, but are not limited to those items listed in Tables II and HI below. 
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Tabic ff 



Transferring from Host to Client 


isochronous video data ! 720x48Q,12bit, 30f/s 


-124.5 Mbps 


isochronous stereo audio data I 44.1kHz, 16bit, stereo 


~ 1.4 Mbps 


asynchronous graphics data 800x600, 12bit, lOf/s, stereo 


-115.2 Mbps 


asynchronous conttol j minimum 


« 1.0 Mbps 


Table III 


Transferring from Client to Host 


isochronous voice data 


8 '<!]/, Sbit 


« 1.0 Mbps 


isochronous video data 


640x480, 12bit, 24f/s 


~ 88.5 Mbps 


asynchronous status, user input.. etc. 


minimum 


« 1.0 Mbps 



[00180] The interface is not fixed but extensible so that it can support the transfer of a 

variety of information "types" which includes user-defined: data, for future system 
flexibility. Specific examples of data to be accommodated are: full-motion video, either in 
the form of full or partial screen bitmap fields or compressed video; static bitmaps at low 
rates to conserve power and reduce miplementation costs; PCM or compressed audio data at 
a variety of resolutions or rates; pointing device position and selection, and user-definable 
data for capabilities yet to be defined. Such data may also be transferred along with control 
or status information to detect device capability or set operating parameters. 

[001S1] Embodiments of the invention advance the art for use in data, transfers that include, 

but are not limited to: watching a movie (video display and audio); using a personal 
computer with limited personal viewing (graphics display, sometimes combined with video 
and audio); playing a video game on a PC, console, or personal device (motion graphics 
display, or synthetic video and audio); "surfing" the Internet, using devices in the form of a 
video phone (bi-directional low-rate video and audio), a camera for still digital pictures, or a 
camcorder for capturing digital video images; using a phone or PDA docked with a 
projector to give a presentation or docked with a desktop docking station connected to a 
video monitor, keyboard, and mouse; and for productivity enhancement or entertainment 
use With cell phones, smart phones, or PDAs, including wireless pointing devices and 
keyboard data. 
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[00182] The mobile data .interface as discussed below is presented in terms of providing 

large amounts of A-V type data over a communication or transfer link which is generally 
configured as a wire-line or cable type link. However, it will be readily apparent that the 
signal structure, protocols, timing, or transfer mechanism could be adjusted to provide a 
link in the form of an optical or wireless media, if it can sustain the desired level of data 
transfer. 

[00 183] The MDD interface signals use a concept known as the Common Frame (CP) for the 

basic signal protocol or structure. The idea behind -using of a Common Frame is to provide 
a synchronization pulse for simultaneous isochronous data streams. A client device can use 
this common frame rate as a time reference. A low CF rate increases channel efficiency by 
decreasing overhead to transmit the sub-frame header. On the other hand, a high CF rate 
decreases the latency, and allows a smaller elastic data buffer for audio samples. The CF 
rate of the present inventive interface is dynamically programmable and may be set at one 
of many values that are appropriate for the isochronous streams used in a particular 
application. That is, the CF value is selected to best suit the given client and host 
configuration, as desired. 

[00184] The number of bytes generally required per common frame, which is adjustable or 
programmable, for isochronous data steams that are most likely to be used with an 
application,, such as for a head-mounted micro-display are shown in Table IV. 

Table IV 



Common Frame Rate (CFR) = 300 Hz 





X 


Y 


Bit 


Frame 
Rate 


Channel 


Rate 
(Mbps) 


Byte/ 
CF 


Computer Game 


720 


480 


24 


30 


1 


248.832 


27000 


Computer 
Graphics 


800 


600 


24 


10 


1 


115.200 


12500 


Video 


640 


480 


12 


29.97 or 
30 


i 


221.184 


92160 


CD Audio 


1 


1 


16 


44100 


, 2 


1.4112 


294 


Voice 


1 


1 


8 


8000 


1 


0.064 


26-2/3 



[001.85] Fractional counts of bytes per common frame are easily obtained using a simple 

programmable M/N counter, structure. For example, a count of 26-2/3 bytes per CF is 
implemented by transferring 2 frames of 27 bytes each followed by one frame of 26 bytes. 



WO 2005/018191 



PC17US2004/026264 



27 

A smaller CF rate may be selected to produce an integer number of bytes per CF. However, 
generally speaking, to implement a simple M/M counter in hardware should require less 
area within an integrated circuit chip or electronic module used to implement part or al l of 
embodiments of the invention than the area needed for a larger audio sample FIFO buffer. 

[001S6] An exemplary- application that illustrates the impact of different data transfer rates 

and data types is a Karaoke system. For Karaoke, a system where an end user, or users, 
sings along with a music video program. Lyrics of the song are displayed somewhere on, 
typically at the bottom of, a screen so the user knows the words to be sung, and roughly the 
timing of the song. This application requires a video display with infrequent graphics 
updates, and mixing of the user's voice, or voices, with a stereo audio stream. 

[00187J If one assumes a common frame rate of 300 Hz, then each CF will consist of: 92.160 

bytes of video content and 588 bytes of audio content (based on 147 16-bit samples, in 
stereo) over the forward link to the client display device, and an average of 26.67 (26-2/3) 
bytes of voice are sent back from a microphone to the mobile Karaoke machine. 
Asynchronous packets are sent between the host and the display, possibly head, mounted. 
This includes at most 768 bytes of graphics data (quarter-screen height), and less than about 
200 bytes (several) bytes for miscellaneous control and status commands. 

[00188] Table V, shows how data is allocated within a Common Frame for the Karaoke 
example. The total rate being used is selected to be about 225 Mbps. A slightly higher rate 
of 226 Mbps allows about another 400 bytes of data per sub-frame to be transferred which 
allows the use of occasional control and status messages. 



Table V 



Element Rate 


Bytes/CF 


Music Video at 640 x 450 pixels and 30 fps 


92160 


Lyric Text at 640 x 120 pixels and 1 fps 


768 


CD Audio at 44,100 sps, stereo, 16-bit 


588 


Voice at 8,000 sps, mono. 8-bit 


26.67 


Sob-frame Header 


19 


Reverse Link Overhead 


26.67+2*9+20 


Total Bytes/CF 


93626.33 


Total Sate (Mbps) 


224.7032 
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1 L(l ontlnned) High Rate Digital Data Interface System Architecture 
E, 'Link Layer 

[00189] Data transferred using the MDD interface high-speed serial data signals consists of a 

stream of time-multiplexed packets that are linked one after the other. Even when a 
tomsmitting device has no data to send, a MDDI link controller generally automatically 
sends filler packets, thus, maintaining a stream of packets. The use of a simple packet 
structure ensures reliable isochronous timing for video and audio signals or data streams. 

[00190] Groups of packets are contained within signal elements or structures referred to as 

sub-frames, and groups of sub-frames are contained within signal elements or structures 
referred to as a media-frame. A sub-frame contains one or more packets, depending on 
their respective size and data transfer uses, and a media-frame contains one more sub- 
frames. The largest sub-frame provided by the protocol employed by the embodiments 
presented here is on the order of 232-1 or 4,294,967,295 bytes, and the largest media-frame 
size then becomes on the order of 216-1 or 65,535 sub-frames. 

[00191] A special header packet contains a unique identifier that appears at the beginning of 
each sub-frame, as is discussed below. That identifier is also used for acquiring the frame 
timing at the client device when communication between the host and client is initiated. 
Link timing acquisition is discussed in more detail below. 

[00192] Typically, a display screen is updated once per media-frame when full-motion video 
is being displayed. The display frame fate is the same as the media-frame rate. The link 
protocol supports full-motion Video over an entire display, or just a small region of full- 
motion video content surrounded by a static image, depending on the desired application. 
In some low-power mobile applications, such as viewing web pages or email, the display 
screen may only need to be updated occasionally. In those situations, it is advantageous to 
transmit a single sub-frame and then shut down or inactivate the link to minimize power 
consumption. The interface also supports effects such as stereo vision, and handles 
graphics primitives. 

[00193] Sub-frames allow a system to enable the transmission of high-priority packets on a 

periodic basis. This allows simultaneous- isochronous streams to co-exist with a minimal 
amount of data buffering. This is one advantage embodiments provide to the display 
process, allowing multiple data streams (high speed communication of video, voice, 
control, status, pointing device data, etc.) to essentially share a common channel. It 
transfers information using relatively few signals. It also enables display-technology- 
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specific actions to exist such as horizontal sync pulses and blanking intervals for a CRT 
monitor. 



F. Link Controller 

[00194] The MDDI link controller shown in PIGS. 4 and 5 is manufactured or assembled to 

be a completely digital implementation with the exception of the differential line receivers 
which are used to receive MDDI data and strobe signals. However, even the differential 
line drivers and receivers can be implemented in the same digital integrated circuits with the 
link controller, such as when making a CMOS type IC. No analog functions or phase lock 
loops (1'LLs) are required for bit recovery or to implement the hardware for the link 
controller, The host and client link controllers contain very similar functions, with the 
exception of the client interface which contains a state machine for link synchronization. 
Therefore, the embodiments of the invention allow the practical advantage of being able to 
create a single controller design or circuit that can be configured as either a host or client, 
which can reduce manufacturing costs for the link controllers, as a whole. 

IV. Interface Link Protocol 
A. Frame structure 

[00195] The signal protocol or frame structure used to implement the forward link 
communication for packet transfer is illustrated in FIG. 6. As shown in FIG. 6, information 
or digital data is grouped into elements known as packets. Multiple packets are in turn 
grouped together to form what are referred to as a ''sub-frame," and multiple sub-frames are 
in turn grouped together to form a "media" frame. To control the formation of frames and 
transfer of sub-frames, each sub-frame begins with a specially predefined packet referred to 
as a Sub-frame Header Packet (SEP). 

[00196] The host device selects the data rate to be used for a given transfer. This rate can be 

changed dynamically by the host device based on both the maximum transfer capability of 
the host, or the data being retrieved from a source by the host, and the maximum capability 
of the client, or other device the data is being transferred to. 

[00197] A recipient client device: designed for, or capable of, working with the MDDI or 

inventive signal protocol is able to be queried by the host to determine the maximum, or 
current maximum, data transfer rate it can use, or a default -slower minimum rate may be 
used, as well as useable data types and features supported. This information could be 
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transferred using a Display Capability Packet (DCP), as discussed further below. The client 
display device is capable of transferring data or corxmmnicating with other devices using the 
interface at a pre-selected minimum data rate or within a minimum data rate range, and the 
host will perform a query using a data rate within this range to determine the full 
capabilities of the client devices. 
[001 98] Other status information defining the nature of the bitmap and video frame-rate 

capabilities of the display can be transferred in a status packet to the host so that the host 
can configure the interface to be as efficient or optimal as practical, or desired within any 
system constraints. 

[00199] The host sends tiller packets when there are no (more) data packets to be transferred 

in the present sub-frame, or when the host cannot transfer at a rate sufficient to keep pace 
with the data transmission rate chosen for the forward link. Since each sub-frame begins 
with a sub-frame header packet, the end of the previous sub-frame contains a packet (most 
likely a filler packet) the exactly fills the previous sub-frame. In the case of a lack of room 
for data bearing packets per se, a filler packet will most likely be the last packet in a sub- 
frame, or at the end of a next previous sub-frame and before a sub-frame header packet. It 
is the task of the control operations in a host device to ensure that there is sufficient space 
remaining in a .sub-frame for each packet to be transmitted within that sub-frame. At the 
same time, once a host device initiates the sending of a data packet, the host must be. able to 
successfully complete a packet of that size within a frame without incurring a data under- 
run condition. 

[00200] In one aspect of embodiments, sub-frame transmission has two modes. One mode is 

a periodic sub-frame mode, or periodic timing epochs, used to transmit live video and audio 
streams. In this mode, the Sub-frame length is defined as being non-zero. The second 
mode is an asynchronous or non-periodic mode in which frames are used to provide bitmap 
data to a client only when new information is available. This mode is defined by setting the 
sub-frame length to zero in the Sub-frame Header Packet. When using the periodic mode, 
sub-frame packet reception may commence when the display has synchronized to the 
forward link frame structure. This corresponds to the "in sync" states defined according to 
the state diagram discussed below with respect to FIG.- 49 or FIG, 63. In the asynchronous 
non-periodic sub-frame mode, reception commences after me first Sub-frame Header 
packet is received. 
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B, Overall Packet Structure 

[00201] The format or structure of packets used to formulate the signaling protocol 

implemented by the embodiments are presented below, keeping in mind that the interface is 
extensible and additional packet structures can be added as desired. The packets are labeled 
as, or divided into, different "packet types" in terms of their function in the interface, that is, 
commands or data they transfer. Therefore, each packet- type denotes a pre-defined packet 
structure for a given packet which is used in manipulating the packets and data being 
transferred. As will be readily apparent, the packets may have pie-selected lengths or have 
variable or dynamically changeable lengths depending on their respective functions. The 
packets could also bear differing names, although the same function is still realized, as can 
occur when protocols are changed during acceptance into a standard. The bytes or byte 
values used in the various packets are configured as multi-bit (8- or 16-bit) unsigned 
integers. A summary of the packets being employed along with their "type" designations, 
listed in type order, is shown in Tables VI- 1 through VI-4, 

[00202] Each table represents a general "type" of packet within the overall packet structure 
for ease in illustration and understanding. There is no limitation or other impact implied or 
being expressed for the invention by these groupings, and the packets can be organized in 
many Other fashions as desired. The direction in which transfer of a packet is considered 
valid is also noted. 



Table VI -1 

Link Control Packets 



Packet Name 


Packet 

1 ■! ■ 


Forward 


Valid in 
R.tr-'tr^ 


Sub-frame Header Packet 








Filler Packet 


0 


x 1 x 


.Reverse Link Encapsulation Packet. 


65 1 x 




Link Shutdown Packet 


69 






Interface Type Handoff Request Packet 


75 






Interface Type Acknowledge Packet 


76 




X 


Perform Type Handoff Packet 


77 






Round Trip Delay Measurement Packet 


82 


X 




Forward Link Skew Calibration Packet 




X 
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Table VI -2. 
Basic Media Stream Packets 



Packet: Name 


Packet 
Type 


Valid ill 
Forward 


Valid in 
Reverse 


Video Stream Pad - . 


16 


X 


X 


Audio Stream Packet 


32 


X 


X 


Reserved Stream Packets 


1 - 15, 

18- 
31, 
33 - 
55 




X 








User-Defined Stream Pack -l ; 


56-63 


X 


X 


Color Map Packet 


64 




X 


Forward Audio Channel Enable Packet 


78 


X 




Reverse Audio Sample Rate Packet 


79 


X 




Transparent Color Enable Packet 


81 






Table VI -3 

Display Status arid Control Packets 


Packet Name 


: -r! 

Type 


Valid in 
Forward 


Valid in 
Reverse 


Display Capability Packet 


66 




X 


Keyboard Data Packet 


67 


A 


X 


Pointing Device Data Packet 


68 




X 


Display Request and Status Packet 


70 




X 


Digital Content Protection Overhead 
Packet 


80 


X 




Request VCP Feature Packet. 


128 


X 




VCP Feature Reply Packet 


129 




X 


Set VCP Feature Packet 


130 


X 




Request Valid Parameter Packet 


131 


X 




Valid Paran V •!•, kct 


132 




X 


t -us: Specific Status Packet 


138 


X 




Valid Status Reply List Packet 


139 




X 


Packet Processing Delay Parameters 
Packet 


140 




X. 


Personal Display Capability Packet 


141 




x. 


Display Error Report Packet 


142 




X 


Scaled Video Stream Capability Packet 


143 




X 


Display Identification Packet 


144 




X 


Alternate Di so \ < pi til Packet 


145 




X 




146 




X 
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Table VI -4 
Advanced Graphic and Display Packets 





Packet 


Valid in 


Valid in 


Packet Name 


Type 


Forward 


Rerarse 


Bit Block Transfer Packet 


71 


X 




Bitmap Area Fill Packet 








Bitmap Pattern Fill Packet 








Read Frame Buffer Packet 


74 


x 




Alpha-Cursor Image Capability Packet 


133 




X 


Alpha-Cursor Transparency Map 
Packet 


134 


X 




Alpha-Cursor Image Offset Packet 


135 


X 




Alpha-Cursor Video Stream Packet 




X 




Scaled Video Stream Capability Packet 


143 




X 


Scaled Video Stream Setup Packet 


136 


X 




Scaled Video Stream 


137 




X 


Acknowledgement Packet 








Scaled Video Stream Packet 


18 


X 





[00203] Something that is clear from other discussions within this text is that while the 

Reverse Encapsulation Packet, Display Capability Packet, and Display Request and Status 
Packet are each considered very important too or even required for External Mode 
operation, they can be considered optional for Internal Mode operation. This creates yet 
another type of MDD interface protocol which allows communication of data at very high 
speeds with a reduced set of communications packets, and corresponding simplification of 
control and timing. 

[00204] Packets have a common basic structure or overall set of minimum fields comprising 
a Packet Length field, a Packet Type field, Data Bytes ficld(s), and a CRC field, which is 
illustrated in FIG, 7. As shown in FIG. 7, the Packet Length field contains information, in 
the form of a multi-bit or -byte value, that specifies the total number of bits in the packet, or 
its length between the packet length field and the CRC field.; In one embodiment, the 
packet length field contains a 16-bit or 2-byte wide, unsigned' integer, that specifies the 
packet length. The Packet Type field is another multi-bit field which designates the type of 
information that is contained within the packet. In an exemplary embodiment, this is an 16- 
bit or 2-byte wide value, in the form of an 16-bit unsigned integer, and specifies such data 
types as display capabilities, handoff, video or audio streams, status, and so forth. 
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[00205] A third, field, is the Data Bytes field, which, contains, the bits or data being transferred 

or sent between the host and client devices as part of that packet. The format of the data is 
defined specifically for each packet type according to the specific type of data being 
transferred, and may be separated into a series of additional fields, each with its own format 
requirements. That is, each packet type will have a defined format for this portion or field. 
The last field is the CRC field which contains the results of a 16-bit cyclic: redundancy 
check calculated over the Data Bytes, Packet Type, and Packet Length fields, which is used 
to confirm the integrity of the information in the. packet. In other words, calculated over the 
entire packet except for the CRC field itself. The client generally keeps a total count of the 
CRC errors detected, and reports this count back to the host in the Display Request and 
Status Packet (see further below). 

[00206] Generally, these field widths and organization are designed to keep 2-bytc fields 

aligned on an even byte boundary, and 4-byte fields aligned on 4-byte boundaries. This 
allows packet structures to be easily built in a main memory space of, or associated with, a 
host and a client without violating the data-type alignment rules encountered for most or 
typically used processors or control circuits. - 

[00207] During transfer of the packets, fields are transmitted starting with the Least 
Significant Bit (LSB) first and ending with the Most Significant Bit (MSB) transmitted last. 
Parameters that are more than one byte in length are transmitted using the least significant 
byte first, which results in the same bit transmission pattern being used for a parameter 
greater than 8 bits in length, as is used for a shorter parameter where the LSB is transmitted 
first. The data fields of each packet are generally transmitted in the order that they are 
defined in the subsequent sections below, with She first field listed being transmitted first, 
and the last field described being transmitted last. The data on the MDDLPataO signal path 
is aligned with bit '0' of bytes transmitted on the interface in any of the modes, Typed, 
Type-II, Type-Ill, or Type-TV. The 

[00208] When manipulating data for displays, the data for arrays of pixels are transmitted by 

rows first, then columns, as is traditionally done in the electronics arts. In other words, all 
pixels that appear in the same row in a bit map are transmitted in order with the left-most 
pixel transmitted first and the right-most pixel transmitted last. After the right-most pixel of 
a row is transmitted then the next pixel in the sequence is the: left-most pixel of the 
following row. Rows of pixels sire generally transmitted, in order from top to bottom for 
most displays, although other configurations can be accommodated as. needed. 
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Furthermore, in handling bitmaps, the conventional .approach, which is followed here, is to 
define a reference point by labeling the upper-left corner of a bitmap as location or offset 
"0,0." The X and Y coordinates used to define or determine a position in the bitmap 
increase in value as one approaches the right and bottom of the bitmap, respectively. The 
first row and first column {upper left corner of an image) start with an index value of zero. 
The magnitude of the X coordinate increases toward the right side of the image, and the 
magnitude of the Y coordinate increases toward the bottom of the image as viewed by the 
user of the display. 

100209] A display window is the visible portion of a bitmap, the portion of the pixels in the 

bitmap that can be seen by the user on the physical display medium. It is often the case that 
the display window and the bitmap are the same size. The upper-left corner of a display 
window always displays bitmap pixel location 0,0. The width of the display window 
corresponds to the X axis of the bitmap, and the display window width shall be less than or 
equal to the width of the corresponding bitmap. The height of the window corresponds to 
the Y axis of the bitmap, and the display window height shall be less than or equal to the 
height of the corresponding bitmap. The display window itself is not addressable in the 
protocol because it is only defined as the visible portion of a bitmap. The relationship 
between a bitmap and display window is illustrated in . 

C. Packet Definitions 

J. Sub-Frame Header Packet 

[00210] The Sub-Frame Header packet is the first packet of every sub-frame, and has a basic- 

structure as illustrated in FIG. 8. The Sub-Frame Header Packet is used for host-client 
synchronization, every host should be able to generate this packet, while every client should 
be able to receive and interpret this packet. As can be seen in FIG. 8, this type of packet is 
structured to have Packet Length, Packet Type, Unique Word, Reserved 1, Sub-Frame 
Length, Protocol Version, Sub-Frame Count, and Media-frame Count fields, generally in 
that order. In one embodiment, this type of packet is generally identified as a Type 15359 
(0x3bff hexadecimal) packet and uses a pre-selected fixed length of 20 bytes, not including 
the packet length field. 

[0021 1] The- Packet Type field and the Unique Word field each use a 2 byte value (16-bit 

unsigned integer).. The 4-byte combination of these two fields together forms a 32-bit 
unique word with good autocorrelation, hi one embodiment, the actual unique word is 
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0x005 a3bff, where the lower 16 bits are transmitted first as the Packet Type, and the most 
significant 16 bits are transmitted afterward. 

[00212] The Reserved 1 Held contains 2 bytes that is reserved space for future use, and is 

generally configured at this point with ail bits set to zero. A purpose of this field is to cause 
subsequent 2 byte fields to align to a 16-bit word address and cause 4- byte fields to align to 
a 32-bit word address. The least significant byte is reserved to indicate that the host is 
capable of addressing multiple client devices. A value of zero is reserved to indicate that 
the host is capable of operating only with a single client device. 

[0021 3] The Sub- frame Length field contains 4 bytes of information or values that specifies 

the number of bytes per sub-frame. In one embodiment, the length of this field may be set 
equal to zero to indicate that only one sub-frame will be transmitted by the host before the 
link is shut down into an idle state. The value in this field can be dynamically changed "on- 
the-fly" when transitioning from one sub-frame to the next. This capability is useful in 
order to make- minor timing adjustments in the sync pulses for accommodating isochronous 
data streams. If the CRC of the Sub-frame Header packet is not valid then the link 
controller should use the Sub-frame Length of the previous known-good Sub-frame Header 
packet to estimate the length of the current sub-frame. 

[00214] The Protocol Version field contains 2 bytes that specify the protocol version used by 

the host. The Protocol Version field is set to '0' to specify the first or Current version of the 
protocol as being used. This value will change over time a$ new versions are created. The 
Sub-frame Count field contains 2 bytes that specify a sequence number that indicates the 
number of sub-frames that have been transmitted since the beginning of the media-frame. 
The first sub-frame of the media-frame has a Sub-frame Count of zero. The last sub-frame 
of the media-frame has a value of n-1, where n is the number of sub-frames per media- 
frame. Note that if the Sub-frame Length is set equal to zero (indicating a non-periodic 
sub-frame) then the Sub-frame count must also be set equal to zero. 

[00215] The Media-frame Count field contains 4 bytes (32-bit unsigned integer); that specify 

a sequence number that indicates the number of media-frames that have been transmitted 
since the beginning of the present media item or data being transferred. The first media- 
frame of a media item has a Media^frame Count of zero. The Media-frame Count 
increments just prior to the. first sub frame of each media-frame and wraps back to zero, 
after the maximum Media-frame Count (for example, media-frame number 232-1 = 
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4,294,967,295) is used. The Media-frame Count value may be reset generally at any time 
by the Host to suit the needs of an end application. 

2. Fitter Packet 

[00216] A filler packet is a packet that is transferred to, or from, a client device when no 

other information is available to be sent on either the forward or reverse: link. It is 
recommended that filler packets have a minimum length in order to allow maximum 
flexibility in sending other packets when required. At the very end of a sub-frame or a 
reverse link encapsulation packet (see below), a link controller sets the size of the filler 
packet to fill the remaining space to maintain packet integrity. The Filler Packet is useful to 
maintain timing on the link when the host or client have no information; to send or 
exchange. Every host and client needs to be able to send and receive this packet to make 
effective use of the interface. 

[0Q217] The format and contents of a Filler Packet are shown in FIG * 9. As shown in FIG. 9, 

this type of packet is structured to have Packet Length, Packet Type, Filler Bytes, and CRC 
fields. In one embodiment, this type of packet is generally identified as a Type 0, which is 
indicated in the 2-byte Type field. The bits or bytes in the Filler Bytes field comprise a 
variable number of all zero bit values to allow the filler packet to be the desired length. The 
smallest filler packet contains no bytes in this field. That is, the packet consists of only the 
packet length, packet type, and CRC, and in one embodiment uses a pre-selected fixed 
length of 6 bytes or a Packet Length value of 4. The CRC value is determined for all bytes 
in the packet including the Packet Length, which may be excluded in some other packet 
types. 

3. Video Stream Packet 
[0.0218] Video Stream Packets carry video data to update typically rectangular regions of a 

display device. The size of this region may be as small as a single pixel or as large as the 
entire display. There may be an almost unlimited number of streams displayed 
simultaneously, limited by system resources, because all context required to display a 
stream is contained within the Video Stream Packet. The. format, of one embodiment of the 
Video. Stream Packet (Video Data Format Descriptor), is shown in FIG. 10. As seen in 
FIG. 10, in one embodiment, this type of packet is -structured to have Packet Length (2 
bytes), Packet Type, bCIient ED, Video Data Descriptor, Pixel Display Attributes, X Left 
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Edge, Y Top Edge, X Eight Edge, Y Bottom Edge, X and Y Start, Pixel Count, Parameter 
CRC, Pixel Data, and CRC fields. This type of packet is generally identified as a Type 16, 
which is indicated in the 2-byte Type field. In one embodiment, a Client indicates an ability 
to receive a Video Stream Packet using RGB, Monochrome, and Y Cr Cb Capability fields 
of the Display Capability Packet. 

[00219] In one embodiment, the bClient ID field contains 2 bytes of information that are 
reserved for a Client ID. Since this is a newly developed communications protocol actual 
client IDs are not yet known or sufficiently communicable. Therefore, the bits in this field 
are generally set equal to zero until such ID values are known, at which time the ID values 
can be inserted or used, as would be apparent to those skilled in the art. 

[00220] The common frame concept discussed above is an effective way to minimize the 
audio buffer size and decrease latency. However, for video data it may be necessary to 
spread the pixels of one video frame across multiple Video Stream Packets within a media- 
frame. It is also very likely that the pixels in a single Video Stream Packet will not exactly 
correspond to a perfect rectangular window on the display. For the exemplary video frame 
rate of 30 frames per second, there are 300 sub-frames per second, which results in, 10 sub- 
frames per media-frame. If there are 480 rows of pixels in each frame, each Video Stream 
Packet in each sub-frame will contain 48 rows of pixels. In other situations, the Video 
Stream Packet might not contain an integer number of rows of pixels. This is true for other 
video frame sizes where the number of sub-frames per media-frame does not divide evenly 
into the number of rows (also known as video lines) per video frame. Each Video Stream 
Packet generally must contain an integer number of pixels, even though it might not contain 
an integer number of rows of pixels. This is important if pixels are more than one byte 
each, or if they are in a packed format as shown in FIG. 12. 

[00221] The format and contents employed for realizing the operation of an exemplary 

Video Data Descriptor field, as mentioned above, are shown in FIGS, 11a -lid. In FIGS. 
11a- lid, the Video Data Format Descriptor field contains 2 bytes in the form of a 16-bit 
unsigned integer that specifies the format of each pixel in the Pixel Data in the present 
stream in the present packet. It is possible that different Video Stream packets may use 
different pixel data formats, that is, use a different value in the Video Data Format 
Descriptor^ and similarly, a stream (region of the display) may change its data format on- 
the-fly. The pixel data format should comply with at least one of the valid formats for the 
client as defined in the Display Capability Packet. The Video Data Format Descriptor 
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defines the pixel format for the present packet only which does not imply that a constant 
format will continue to be used for the lifetime of a particular video stream. 

[00222] FIGS, 11a through lid illustrate how the Video Data Format Descriptor is coded. 
As used in these figures, and in tin's embodiment, when bits [15:13] are equal to '000', as 
shown in FIG. 11a, then the video data consists of an array of monochrome pixels where the 
number of bits per pixel is defined by bits 3 through 0 of the Video Data Format Descriptor 
word. Bits 11 through 4 are generally reserved for future use or applications and are set to 
zero in this situation. When bits [15:13] are instead equal to WV, as shown in FIG. lib, 
then the video data consists of an array of color pixels that each specify a color through a 
color map (palette). In this situation, bits 5 through 0 of the Video Data Format Descriptor 
word define the number of bus per pixel, sad bits 11 through 6 are generally reserved for 
future use or applications and set equal to zero. When bits [15:13] are instead equal to 
'010', as shown in FIG. 11c, then the video data consists of an array of color pixels where 
the number of bits per pixel of red is defined by bits 11 through 8, the number of bits per 
pixel of green is defined by bits 7 through 4, and the number of bits per pixel of blue is 
defined by bits 3 through 0, In this situation, the total number of bits in each pixel is the 
sum of the number of bits used for red, green, and blue. 

[00223] However, when bits [15:13] are instead equal to 'Oil', as shown in FIG. lid, then 
the video data consists of an array of video data in 4:2:2 YCbCr format with luminance and 
chrominance information, where the number of bits per pixel of luminance (Y) is defined 
by bits 1 1 through 8, the number of bits of the Cb component is defined by bits 7 through 4, 
and the number of bits of the Cr component is defined by bits 3 through 0. The total 
number of bits in each pixel is the sum of the number of bits used for red, green, and blue. 
The Cb and Cr .components are sent at half the rate as Y. In addition, the video samples in 
the Pixel Data portion of this packet are organized as follows: Cbn, Yn, Cm, Yn+1, Cbn+2, 
Yn+2, Crn+2, Yn+3, ... where Cbn and Cm are associated with Yn and Yn+1, and Cbn+2 
and Crn+2 are associated with Yn+2 and Yn+3, and so on. 

[00224] Yn, Yn+1, Yn+2 and Yn+3 are luminance values of four consecutive pixels in a 
single row from left to right. The ordering of the color components is typically chosen to be 
in the same format as the UYVY FOURCC format used by Microsoft Corporation in its 
software, although the invention is not limited to this format. If there are an odd number of 
pixels in a row (X Right Edge - X Left Edge + 1) in the window referenced by the Video 
Stream Packet then the Y value corresponding to the last pixel in each row will be followed 
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by the Cb value of the first pixel of the next row, and a Cr value is not sent for the last pixel 
in the row. It is recommended that windows using Y Cb Cr format have a width that is an 
even numtwi of pixels. The Pixel Data in a packet should contain an even number of 
pixels. It may contain an odd or even number of pixels in the case where the last pixel of 
the Pixel Data corresponds to the last pixel of a row in the window specified in the Video 
Stream Packet header, i.e. when the X location of the last pixel in the Pixel Data is equal to 
X Right Edge. 

[00225] When bits [15:13] are instead equal to '100' then the video data consists of an array 

of Bayer pixels where the number of bits per pixel is defined by bits 3 through 0 of the 
Video Data Formal Descriptor word. The Pixel Pattern is defined by bits 5 and 4 as shown 
in Error! Reference source not found. (Bayer). The order of pixel data may be horizontal 
or vertical and the pixels in rows or columns may be sent in forward or backward order and 
is defined by bits 8 through 6 as shown in Error! Reference source not found.. Bits 11 
through 9 should be set to zero. 

[00226] For all four formats shown in the figures, bit 12, which, is designated as "F\ 
specifies whether or not the Pixel Data samples are packed, or byte-aligned pixel data. A 
value of '0' in this field indicates that each pixel in the Pixel Data field is byte-aligned with 
an MDD interface byte boundary. A value of T indicates that each pixel and each color 
within each pixel in the Pixel Data is packed up against the previous pixel or color within a 
pixel leaving no unused bits. 

[00227] The first pixel in the first video stream packet of a media frame for a particular 

display window will go into the upper left corner of the stream window defined by an X 
Left Edge and a Y Top Edge, and the next pixel received is placed in the next pixel location 
in the same row, and so on. In this first packet of a media frame, the X start value will 
usually be equal to X Left Edge, and Y start value will usually be equal to Y Top Edge. In 
subsequent packets corresponding to the same screen window, the X and Y start values will 
usually be set to the pixel location in the screen window that would normally follow after 
the last pixel sent in the Video Stream Packet that was transmitted in the previous sub- 
frame. 



4. Audio Stream Packet 

[00228] The audio stream packets carry audio data to be played through the audio system of 

the client, or for a stand alone audio presentation device. Different audio data streams may 
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be allocated for separate audio channels in a sound system, for example: left-front, right- 
front, center, left-rear, and right-rear, depending on the type of audio system being used, A 
full complement of audio channels is provided for headsets that contain enhanced spatial- 
acoustic signal processing. A Client indicates an ability to receive an Audio Stream Packet 
using the Audio Channel Capability and Audio Sample Rate fields of the Display 
Capability Packet. The format of Audio Stream Packets is illustrated in FIG. 13. 
[00229] As shown in FIG. 13, this type of packet is structured to have Packet Length, Packet 

Type, bCfient ID, Audio Channel ID, Reserved 1, Audio Sample Count, Bits Per Sample 
and Packing, Audio Sample Rate, Parameter CRC, Digital Audio Data, and Audio Data 
CRC fields. In one embodiment, this type of packet is generally identified as a Type 32 
packet. 

[00230] The bCHen! ID .field contains 2 bytes of information that are reserved for a Client 

ID, as used previously. The Reserved 1 field contains 2 bytes that is reserved for future use, 
and is generally configured at this point with all bits set to zero. 

[00231] The Bits Per Sample and Packing field contains 1 byte in the form of an 8-bit 

unsigned integer that specifies the packing format of audio data. The format generally 
employed is for Bits 4 through 0 to define the number of bits per PCM audio sample. Bit 5 
then specifies whether or not the Digital Audio Data samples are packed. The difference 
between packed and byte-aligned audio samples is illustrated in FIG. 14. A value of '0' 
indicates that each PCM audio sample in the Digital Audio Data field is byte-aligned with 
an MDDI interface byte boundary, and a value of T indicates that each successive PCM 
audio sample is packed up against the previous audio sample. This bit is generally effective 
only when the value defined in bits 4 through 0 (the number of bits per PCM audio sample) 
is not a multiple of eight. Bits 7 through 6 are reserved for future use and are generally set 
at a value -of zero. 

5. Reserved Stream Packets 
[00232] In one embodiment, packet types 1 to 15, 18 to 31, and 33 through 55 are reserved 

for stream packets to be defined for use in future versions or variations of the packet 
protocols, as desired for various applications encountered. Again, this is part of making the 
MDD interface more flexible and useful in the face of ever changing technology and system 
designs as compared to other techniques. 
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6. User-Defined Stream Packets 

[00233] Eight data stream types, known as Types 56 through 63, are reserved for use in 
proprietary applications that may be defined by equipment manufacturers for use with a 
MDDI link. These are known as User-defined Stream Packets. Such packets may be used 
for any purpose, but the Host and Client should only employ such packets in situations 
where the result of such use is very well understood or known. The specific definition of 
the stream parameters and data for these packet types is left to the specific equipment 
manufacturers implementing such packet types or seeking their use. Some exemplary uses 
of the User-defined Stream Packets are to convey test parameters and test results, factory 
calibration data, and proprietary special use data, The format of the user-defined stream 
packets as used in one embodiment is illustrated in FIG. 15, As shown in FIG. 15, this type 
of packet is structured to have Packet Length (2 bytes), Packet Type, bClient ID number, 
Stream Parameters, Parameter CRC, Stream Data, and Stream Data CRC fields. 

7. Color Map Packets 

[00234] The color map packets specify the contents of a color map look-up table used to 
present colors for a client. Some applications may require a color map that is larger than 
the amount of data that can be transmitted in a single packet. In these cases, multiple Color 
Map packets may be transferred, each with a different subset of the color map by using the 
offset and length fields described below. The format of the Color Map Packet in one 
embodiment is illustrated in FIG. 16. As shown in FIG. 16, this type of packet is structured 
to have Packet Length, Packet Type, hClient ID, Color Map Item Count, Color Map Offset, 
Parameter CRC, Color Map Data, and Data CRC fields. In one embodiment, this type of 
packet is generally identified as a Type 64 packet (Video Data Format and Color Map 
Packet) as specified in the Packet Type Field (2 bytes). A Client indicates an ability to 
receive Color Map Packets using the Color Map Size and Color Map Width fields of the 
Display Capability Packet. 

8. Reverse Link Encapsulation Packets 

[00235] In an exemplary embodiment, data is transferred in the reverse direction using a 

Reverse Link Encapsulation Packet A forward link packet is sent and the MDDI link 
operation (transfer direction) is changed or turned around the middle of this packet so that 
packets can be sent in the reverse direction. The format of the Reverse Link Encapsulation 
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packet in one embodiment is illustrated in FIG. 17. As: shown in FIG. 17, this type of 
packet is structured to have Packet Length, Packet Type, hCLient ID, Reverse Link Flags, 
Reverse Rate Divisor, Turn-Around 1 Length, Turn-Around 2 Length, Parameter CRC\ All 
Zero 1, Turn- Around 1, Reverse Data Packets, AH Zero 2, Turn-Around 2, and Driver re- 
enable fields. This type of packet is generally identified as a Type 65 packet. For External 
Mode every host must be able to generate this packet and receive data, and every client 
must be able to receive and send data to the host. Implementation of this packet is optional 
for Internal Mode. 

[00236] The MDDI link controller behaves in a special manner while sending a Reverse 

Link Encapsulation Packet. The MDD interface has a strobe gignnJ that is always driven by 
the host as controller of the link. The host behaves as if it were transmitting a zero for each 
bit of the Turn-Around and Reverse Data Packets portions of the Reverse Link 
Encapsulation packet, The host toggles a MDDI Strobe signal at each bit boundary during 
the two turn-around times and during the tune allocated for reverse data packets. (This is 
the same behavior as if it were transmitting all-zero data.) The host disables its MDDI data 
signal line drivers during the time period specified by Turn-Around 1, and the client re- 
enables its line drivers during, the Driver Re-enable field following the time period specified 
by Turn-Around 2 field. The client reads the Turn-Around Length parameter and drives the 
data signals toward the host immediately after the last bit in the Turn-Around 1 field. That 
is, the client clocks new data into the link on certain rising edges of the MDDI strobe as 
specified in the packet contents description below, and elsewhere. The client uses the 
Packet Length and Turn-Around Length parameters to know the length of time it has 
available to send packets to the host. The client may send filler packets or drive the data 
lines to a zero state when it has no data to send to the host. If the data lines are driven to 
zero, the host interprets this as a packet with a zero length (not a valid length) and the host 
does not accept any more packets from the client for the duration of the current Reverse 
Link Encapsulation Packet. 
[0D237] The Host drives the MDDLData signals to the logic-zero level during the All Zero 1 
field, and a client drives the MDDI data lines to a logic zero level for at least one reverse 
link clock period before the start .of the Turn Around 2 field, that is during the All Zero 2 
field period. This keeps the data- lines in a. deterministic state during the Turn Around 1 and 
Turn Around 2 fields time period. If the client has no more packets to send, it may even 
disable the data lines after driving them to a logic-zero level because the hibernation bias 
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resistors (discussed elsewhere) keep the data lines at a logic-zero level for the remainder of 
the Reverse Data Packets field, or a duration of about 16 forward link bytes or more. 
[00238} In one embodiment, the Reverse link Request Field of the Display Request and 
Status Packet may be used to inform the host of the number of bytes the client needs in the 
Reverse Link Encapsulation Packet to send data back to the host, The host attempts to 
grant the request by allocating at least that number of bytes in the Reverse Link 
Encapsulation Packet. The host may send more than one Reverse Link Encapsulation 
Packet in a sub-frame. The display may send a Display Request and Status Packet at almost 
any time, and the host will interpret the Reverse Link Request parameter as the total number 
of bytes requested in one sub-frame. 

9. Display Capability Packets 
[00239] A host needs to know the capability of the client (display) it is communicating with 

in order to configure the host-to-client link in an generally optimum or desired manner. It is 
recommended that a display send a Display Capability Packet to the host after forward link 
synchronization is acquired. The transmission of such a packet is considered required when 
requested by the host using the Reverse Link Flags in the Reverse Link Encapsulation 
Packet The Display Capability Packet is used to inform the host of the capabilities of a 
display. For External Mode every host must be able to receive this packet, and every 
display must be able to send this packet to fully utilize this interface and protocol. 
Implementation of this packet is optional for Internal Mode, since the capabilities of the 
display should already be well defined and known to the host at the time of manufacture or 

[00240] The format of the Display Capability packet in one embodiment is illustrated in FIG. 

18. As shown in FIG. 18, this type of packet is structured to have Packet Length, Packet 
Type, Protocol Version, Mm Protocol Version, Bitmap Width, Bitmap Height, 
Monochrome. Capability, Color Map Capability, RGB Capability, Y Cr Cb Capability, 
Display Feature Capability, Data Rate Capability, Frame Rate Capability, Audio Buffer 
Depth, Audio Stream Capability, Audio Rate Capability, Min Sub-frame rate, and CRC 
fields. In an exemplary embodiment, this type of packet is generally identified as a Type 66 
packet- 
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10. Keyboard Data Packets 

[00241] A keyboard data packet is used to send keyboard data from the client device to the 

host. A wireless (or wired) keyboard may be used in conjunction with various displays or 
audio devices, including, but not limited to, a head mounted video display/audio 
presentation device. The Keyboard Data Packet relays keyboard data received from one of 
several known keyboard-like devices to the host. This packet can also be used on the 
forward link to send data to the keyboard. A client indicates an ability to send and receive 
Keyboard Data Packets using the Keyboard Data Field in the. Display Capability Packet. 

[00242] The format of a Keyboard Data Packet is show in FIG. 19, and contains a variable 

number of bytes of information from or for a keyboard. As shown in FIG. 19, this type of 
packet is structured to have Packet Length, Packet Type, bClient ID, Keyboard Data 
Format, Keyboard Data, and CRC fields. Here, this type of packet is generally identified as 
a Type 67 packet. 

[00243] The bClient ID is a reserved field, as before, and the CRC is performed over all 
bytes, of the packet. The Keyboard Data Format field contains a 2 bytes value that describes 
the keyboard data format. Bits 6 through 0 should be identical to the Keyboard Data 
Format field in the Display Capability Packet. This value is not to equal 127. Bits 15 
through 7 are reserved for future use and are, therefore, currently set to zero. 

11. Pointing Device Data Packets 

[002441 A pointing device data packet is used to send position information from a wireless 

mouse or other pointing device from the display to the host Data can also be sent to the 
pointing device on the forward link using this packet. An exemplary format of a Pointing 
Device Data Packet is shown in FIG. 20, and contains a variable number of bytes of 
information from or for a pointing device. As shown in FIG. 20, this type of packet is 
structured to have Packet Length, Packet Type, Pointing Device Data, and CRC fields. In 
an exemplary embodiment, this type of packet is generally identified as a Type 68 packet in 
the I-byte type field. 

12. Link Shutdown Packets 

[00245] A Link Shutdown Packet is sent from the host to the client display to indicate that 

the MDDI data and strobe will be shut down and go into a low-power consumption 
"hibernation" state. This packet is useful to shut down the link and conserve power after 
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static bitmaps are sent from, a mobile communication device to the display, or when there is 
no further information to transfer from a host to a client for the time being. Normal 
operation is resumed when the host sends packets again, The first packet sent after 
hibernation is a sub-frame header packet. The format of a Display Status Packet is shown 
in PIG. 21. As shown in FIG. 21, this type of packet is structured to have Packet Length, 
Packet Type, and CRC fields. In one embodiment, this type of packet is generally 
identified as a Type 69 packet in the 1-byte type field, and uses a pre -selected fixed length 
of 3 bytes. 

[00246] In the low-power hibernation state, the MDDI Data driver is disabled into a high- 

impedance state, and the MDDIjData signals are pulled to a logic zero state using a high- 
impedance bias network that can be overdriven by the display. The strobe signal used by 
the interface is set to a logic-zero level in the hibernation state to minimize power 
consumption. Either the host or client may cause the MDDI link to "wake up" from the 
hibernation state as described elsewhere, which is a key advance for and advantage of the 
present invention. 

13 Display Request and Status Packets, 
[00247] The host needs a small amount of information from the display so it can configure 
the host-to-display link in a generally optimum manner. It is recommended that the display 
send owe Display Status Packet to the host each sub-frame. The display should send this 
packet as the first packet in the Reverse Link Encapsulation Packet to ensure that it is 
delivered reliably to the host. The format of a Display Status Packet is shown in FIG. 22. 
As shown in FIG. 22, this type of packet is structured to have Packet Length, Packet Type, 
Reverse Link Request, CRC Error Count, and CRC fields. This type of packet is generally 
identified as a Type 70 packet in the 1-byte type field, and uses a pre-selected fixed length 
of 8 bytes. 

[00248] The Reverse Link Request field may be used to inform the host of the number of 

bytes the display needs in the Reverse Link Encapsulation Packet to send data back to the 
host. The host should attempt to grant the request by allocating at least that number of 
bytes in the. Reverse Link. Encapsulation Packet. The host may send more than one Reverse 
Link Encapsulation Packet, in a sub-frame in order to accommodate data. The client may 
send a Display Request and Status Packet at any time and the host will interpret the Reverse 
Link Request parameter as the total number of bytes requested In one sub-frame. 
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Additional details and specific examples of how reverse link data is sent back to the host are 
shown below. 



14. Bit Block Transfer Packets 

[00249] The Bit Block Transfer Packet provides a means to scroll regions of the display in 

any direction. Displays that have this capability will report the capability in bit 0 of the 
Display Feature Capability Indicators field of die Display Capability Packet. The format of 
a Bit Block Transfer Packet is shown in FIG. 23. As shown in FIG. 23, this type of packet 
is structured to have Packet Length, Packet Type, Upper Left X Value, Upper Left Y Value, 
Window Width, Window Height, Window X Movement, Window Y Movement, and CRC 
fields. This type of packet is generally identified as a Type 71 packet, and uses a pre- 
selected fixed length of 15 bytes. 

[00250] The fields are used to specify the X and Y values of the coordinate of the upper left 

corner of the window to be moved, the width and height of the window to be moved, and 
the number of pixels that the window is to be moved horizontally, and vertically, 
respectively. Positive values for the latter two fields cause the window to be moved to the 
right, and down, and negative values cause movement to the left and up, respectively... 

15. Bitmap Area. Fill Packets 

[00251 J The Bitmap Area Fill Packet provides a means to easily initialize a region of the 

display to a single color. Displays that have this capability will report the capability in bit 1 
of the Display Feature Capability indicators field of the Display Capability Packet. The 
format of a Bitmap Area Fill Packet is shown in FIG. 24. As shown in FIG. 24, this type of 
packet is structured to have Packet Length, Packet Type, Upper Left X Value, Upper Left Y 
Value, Window Width, Window Height, Data Format Descriptor, Pixel Area Fill Value, 
and CRC fields. This type of packet is generally identified as a Type 72 packet in the 1- 
byte type field, and uses a pre selected fixed length of 17 bytes. 

16. Bitmap Pattern Fill Packets 

[00252] The Bitmap Pattern Fill Packet provides a means to easily initialize a region of the 

display to a pre-selected pattern. Displays that have this capability will report the capability 
in bit 2 of the Display Feature Capability Indicators field of the Display Capability Packet. 
The upper left corner of the fill pattern is aligned with the upper left corner of the window 
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to be filled. If the window to "be filled is wider -or taller than the fill pattern, then the pattern 
may repeated horizontally or -vertically a number of times to fill the window. The right or 
bottom of the last repeated pattern is truncated as necessary. If the window is smaller than 
the fill pattern, then the right side or bottom of the fill pattern may be truncated to fit the 
window. 

[00253] The format of a Bitmap Pattern Fill Packet is- shown m FIG. 25. As shown in FIG. 

25, this type of packet is structured to have Packet Length, Packet Type, Upper Left X 
Value, Upper Left Y Value, Window Width, Window Height, Pattern Width, Pattern 
Height, Data Format Descriptor, Parameter CRC, Pattern Pixel Data, and Pixel Data CRC 
. fields. This type of packet is generally identified as a Type 73 packet in the 1 byte type 
field. 

17. Communication Link Data Channel Packets 
[00254] The Communication Link Data Channel Packet provides a means for a display with 
high-level computing capability, such as a PDA, to communicate with a wireless transceiver 
such as a cell phone or wireless data port device. In this situation, the MDDI link is acting 
as a convenient high-speed interface between the communication device and the computing 
device with the mobile display, where this packet transports data at a Data Link Layer of an 
operating system for the device. For example, this packet could be used if a Web browser, 
email client, or an entire PDA were built into a mobile display. Displays that have this 
capability will report the capability in bit 3 of the Display Feature Capability Indicators 
field of the Display Capability Packet. 
[00255] The format of a Communication Link Data Channel Packet is shown in FIG. 26. As 

shown in FIG. 26, this type of packet is structured to have Packet Length, Packet Type, 
Parameter CRC, Communication Link Data, and Communication Data CRC fields, This 
type of packet is generally identified as a Type 74 packet in the type field. 

IS. Interface Type flandoff Request Packets 

IO0256J The Interface Type Handoff Request Packet enables the host to request that the 

client or display shift from an existing or current mode to the Type-I (serial), Type-JI (2-bit 
parallel), Type-in (4-bit. parallel), or Type-FV (8-bit parallel) modes. Before the host 
requests a particular mode it should confirm that the display is capable of operating in the 
desired mode by examining bits 6 and 7 of the Display Feature Capability Indicators field 
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of the Display Capability Packet. The format of a Interface Type- Handoff Request Packet 
is shown in FIG. 27. As shown in FIG. .27, this type of packet is structured to have Packet 
Length, Packet Type, Interface Type, and CRC fields. This type of packet is generally 
identified as a Type 75 packet, and uses a pre-selected fixed length of 4 bytes. 

19. Interface Type Acknowledge Packets 

[00257] The Interface Type Acknowledge Packet is sent by the display to confirm receipt of 

the Interface Type Handoff Packet. The requested mode, Typc-I (serial), Type-H (2-bit 
parallel), Type-Hi (4-bit parallel), or Type-IV (8-bit parallel) mode, is echoed back to the 
host as a parameter in this packet. The format of a Interface Type Acknowledge Packet is 
shown in PIG. 28. As shown in FIG. 28, this type of packet is structured to have Packet 
Length, Packet Type, Interface Type, and CRC fields. This type of packet is generally 
identified as a Type 76 packet, and uses a pre-selected fixed length of 4 bytes. 

20. Perform Type Handoff Packets 

[00258] The Perform Type Handoff Packet is a means for the host to command the display 
to handoff to die mode specified in this packet. This is to be the same- mode that was 
previously requested and acknowledged by the Interface Type Handoff Request Packet and 
Interface Type Acknowledge Packet. The host and display should switch to the agreed 
upon mode after this packet is sent. The display may lose and re-gain link synchronization 
during the mode change. The format of a Perform Type Handoff Packet is shown in FIG. 
29, As shown in FIG. 29, this type of packet, is structured to have Packet Length, Packet 
Type, Packet Type, and CRC fields. This type of packet is generally identified as a Type 77 
packet in the I byte type field, and uses a pre-selected fixed length of 4 bytes. 

21. Forward Audio Channel Enable Packets 

[00259] This packet allows the host to enable or disable audio channels in the display. This 
capability is useful so the display (client) can power off audio amplifiers or similar circuit 
elements to save power when there is no audio to be output by the host. This is 
significantly more difficult to implement implicitly simply using the presence: or absence of 
audio streams as an indicator. The default state when the display system is powered-up is 
that all audio channels are enabled. The format of a Forward Audio Channel Enable Packet 
is shown in FIG. 30. As shown in FIG 30, this type of packet is structured to have Packet 
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Length, Packet Type, Audio Channel Enable Mask, and CRC fields. This type of packet is 
generally identified as a Type 78 packet in the 1-byte type field, and uses a pre-selcctcd 
fixed length, of 4 bytes. 

22. Reverse Audio Sample Rate Packets 

[00260] This packet allows the host to enable or disable the reverse-link audio channel, and 

to set the audio data sample rate of this stream. The host selects a sample rate that is 
defined to be valid in the Display Capability Packet If the host selects an invalid sample 
rate Uien the display will not send an audio stream to the host. The host may disable the 
reverse-link audio stream by setting the sample rate to 255. The default state assumed when 
the display system is initially powered-up or connected is with the reverse-link audio stream 
disabled. The format of a Reverse Audio Sample Rate Packet is shown in FIG. 31, As 
shown in FIG. 31, this type of packet is structured to have Packet Length, Packet Type, 
Audio Sample Rate, and CRC Fields, This type of packet is generally identified as a Type 
79 packet, and uses a pre-selected fixed length of 4 bytes. 

23. Digital Content Protection Overhead Packets 

[00261] This packet allows the host and a display to exchange messages related to the digital 

content protection method being used, Presently two types of content protection are 
contemplated, Digital Transmission Content Protection (DTCP), or High-bandwidth Digital 
Content Protection System (HDCP), with room reserved for future alternative protection 
scheme designations. The method being used is specified by a Content Protection Type 
parameter in this packet. The format of a Digital Content Protection Overhead Packet is 
shown in FIG. 32. As shown in FIG. 32, this type of packet is structured to have Packet 
Length, Packet Type, Content Protection Type, Content Protection Overhead Messages, and 
CRC fields. This type of packet is generally identified as a Type 80 packet, 

24. Transparent Color Enable Packets 

[00262] The Transparent Color Enable Packet is used to specify which color is transparent in 

a display and to enable or disable the use of a transparent color for displaying images- 
Displays that have this capability will report that capability in bit 4 of the Display Feature 
Capability Indicators field of the Display Capability Packet, When a pixel with the value 
for transparent color is written to the bitmap, the color does not change from the previous 
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value. The format of a Transparent Color Enable Packet is shown in FIG. 33. As shown in 
FIG. 33, this type of packet is structured to have Packet Length, Packet Type, Transparent 
Color Enable, Data Format Descriptor, Transparent Pixel Value, and CRC fields. This type 
of packet is generally identified as a Type- 81 packet in the 1-byte type field, and uses a pre- 
selected fixed length of 10 bytes. 

25. Round Trip Delay Measurement Packets 

[00263] The Round Trip Delay Measurement Packet is used to measure the propagation 

delay from the host to a client (display) pins the Delay from the client (display) back to the 
host. This measurement inherently includes the delays that exist in the line drivers and 
receivers, and an interconnect sub-system. This measurement is used to set the turn around ; 
delay and reverse link rate divisor parameters in the Reverse link Encapsulation Packet, 
described generally above. This packet is most useful when the MDDI link is running at 
the maximum speed intended for a particular application. The MDDI_Stb signal behaves as 
though all zero data is being sent during the following fields: All Zero, both Guard Times, 
and the Measurement Period. This causes MDDIJStb to toggle at half the data rate so it can 
be used as periodic clock in the display during the Measurement Period, 

[00264] The format of a of Round Trip Delay Measurement Packet is shown in PIG. 3:4 As 
shown in FIG. 34, this type of packet is structured to have Packet Length, Packet Type, 
Parameter CRC, All Zero, Guard Time 1, Measurement Period, Guard Time 2, and Driver 
Re-enable fields. This type of packet is generally identified as a Type 82 packet, and uses a 
pie-selected fixed length of 533 bits. 

[00265] The timing of events that take place during the Round Trip Delay Measurement 

Packet are illustrated in FIG. 35. In FIG. 35, the host transmits the Round Trip Delay- 
Measurement Packet, shown by the presence of the Parameter CRC and Strobe Alignment 
fields followed by the All Zero and Guard Time 1 fields. A delay 3502 occurs before the 
packet reaches the client display device or processing circuitry. As the display receives the 
packet, it transmits the Oxff, Oxff, 0x0 pattern as precisely as practical at the beginning of 
the Measurement Period as determined by the display. The actual time the display begins to 
transmit this sequence is delayed from the beginning of the Measurement Period from the 
point of view of the host. The amount of this delay is- substantially the time it takes for the 
packet to propagate through the line drivers and receivers and the interconnect subsystem. 
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A similar amount of delay 3504 is incurred for the- pattern to propagate from the display 
back to the host. 

[00266] In order to accurately determine the round trip delay time for signals traversing to 

and from the client, the host counts the number of bit time periods occurring after the start 
of the Measurement Period until the beginning of the Oxff, Oxff, 0x0 Sequence is detected 
upon arrival. This information is used to determine the amount of time for a round trip 
signal to pass from the host to the client and back again. Then, about one half of this 
amount is attributed to a delay created for the one way passage of a signal to the client 

[00267] The display disables its line drivers substantially immediately after sending the last 

bit of the Oxff, Oxff, 0x0 pattern. Guard Time 2 allows time for the display's line drivers to 
go completely to the high-impedance state before the host transmits the Packet Length of 
the next packet. The hibernation pull-up and pull-down resistors (see FIG. 42) ensure that 
the MDDIJData signals are held at a valid low level in the intervals where the line drivers 
are disabled in both the host and display. 



26, Forward Link Skew Calibration Packet 
.[00268] The Forward Link Skew Calibration Packet allows a client or Display to calibrate 
itself for differences in the propagation delay of the MDDI JData signals with respect to the 
NDDDLJStb signal. Without delay skew compensation, the maximum data rate is generally 
limited to account for potential worst-case variation in these delays. Generally, this packet 
is only sent when the forward link data rate is configured to a rate of around 50 Mbps or 
lower. After sending this packet to calibrate the display, the data rate may be stepped up 
above 50 Mbps. If the data rate is set too high during the skew calibration process, the 
display might synchronize to an alias of the bit period which could cause the delay skew 
compensation setting to be off by more than one bit time, resulting in erroneous data 
clocking. The highest data rate type of interface or greatest possible Interface Type is 
selected prior to sending the Forward Link Skew Calibration Packet so that all existing data 
bits are calibrated. 

[00269] The format of a Forward Link Skew Calibration Packet is shown in FIG. 56. As 

■shown. in FIG. 56, this type of packet is structured to have Packet Length (2 bytes), Packet 
Type, Parameter CRC, Calibration Data -Sequence, and CRC fields. This type of packet is 
generally identified as a Type S3 packet in the type field, and has a preselected length of 
515. 
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Virtual Control Panel 

[00270J The use of a Virtual Control Panel (VCP) allows a host to set certain user controls in 

a client. By allowing these parameters to be adjusted by the host, the user interface in the 
client can be simplified because screens that allow a user to adjust parameters such as audio 
volume or display brightness can be generated by host software rather than by one or more 
microprocessors in the client. The host has the ability to read the parameter settings in the 
client and to determine the range of valid values for each control. The client has the 
capability to report back to the host which control parameters can be adjusted. 

[00271] The control codes (VCP Codes) and associated data values generally specified, are 

utilized to specify controls and. settings in the client. The VCP Codes in the MDDT 
specification are expanded to 16 bits to preserve proper data field alignment in the packet 
definitions, and in the future to support supplementary values that are unique to this 
interface or future enhancements. 

27. Request VCP Feature Packet 

[00272] The Request VCP Feature Packet provides a means, mechanism, or method for the 
host to request the current setting of a specific control parameter or all valid control 
parameters. Generally, a client responds to a VC P Packet with the appropriate information 
in a VCP Feature Reply Packet. In one embodiment, the client indicates an ability to 
support the Request VCP Feature Packet using bit 20 of the Display Feature Capability 
Indicators field of the Display Capability Packet. 

[00273] The format of the Request VCP Feature Packet in one embodiment is shown in 

FIG. 69. As seen in FIG. 69, this type of packet is structured to have Packet Length, Packet 
Type, hClient ID, MCCS VCP code, and CRC fields. This type of packet is generally 
identified in one embodiment as a Type 128, which is indicated in the 2 byte- type field. 
The packet length, which specifies the total number of bytes In the packet not including the 
packet length field, is typically fixed for this type of packet at a length of : 8 bytes. 

[00274] The hClient ED field contains a 16-bit unsigned integer reserved for the Client ID. 

This field is reserved far future use and is typically set to zero. The MCCS VCP Code field 
comprises 2 bytes of information that specifies the MCCS VCP Control Code Parameter, A 
value in the range of 0 to 255 causes a VCP Feature Reply Packet to be returned with a 
single item in the VCP Feature "Reply List corresponding to the specified MCCS code. An 
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MCCS VCP Code of 65535 (Oxffff) requests a VCP Feature Reply Packet with a VCP 
Feature Reply List containing a Feature Reply list Item for each control supported by the 
client. The values of 256 through 65534, for this field are reserved for future use and 
presently not in use. 

28. VCP Feature Reply Packet 

[00275] The VCP Feature Reply Packet provides a means, mechanism, or method for a 

client to respond to a host request with the current setting of a specific control parameter or 
all valid 'control parameters. Generally, the client sends the VCP Feature Reply Packet in 
response to the Request VCP Feature Packet, Tins packet is useful to determine the current 
setting of a specific parameter, to determine the valid range for a specific control, to 
determine if a specific control is supported by the client, or to determine the set of controls 
that arc supported by the client. If a Request VCP Feature is sent that references a specific 
control that is not implemented in the client then a VCP Feature Reply Packet is returned 
with a single VCP Feature Reply List item corresponding to the ^implemented control that 
contains the appropriate error code. In one embodiment, the client indicates an ability to 
support the VCP Feature Reply Packet using bit 20 of the Display Feature Capability 
Indicators field of the Display Capability Packet. 

[00276] The format of the VCP Feature Reply Packet in one embodiment is shown in 
FIG. 70. As seen in FIG. 70, this type of packet is structured to have Packet Length, Packet 
Type, cClient ID. MCCS Version, Reply Seqeunce Number, VCP Feature Reply List, and 
CRC fields. TliiS type of packet is generally identified in one embodiment as a Type 129, 
as indicated in the 2 byte type field. 

[00277] The cClient ID field contains information reserved for a. Client ID. This field is 

reserved for future use and is generally set to zero. MCCS Version field contains 2 bytes of 
information that specifies the Version of the VESA MCCS Specification implemented by 
the client. 

[00278] The 2 byte Reply Sequence Number field contains information or data that specifies 

the sequence number of the VCP Feature Reply Packets returned by the client. The client 
returns one or more VCP Feature Reply- Packets in response to a Request VCP Feature 
Packet with an MCCS Control Code value of 65535. The client may spread the feature 
reply list over multiple VCP Feature Reply Packets. In this case, the client assigns a 
sequence number to each successive packet, and the sequence numbers of the VCP Feature 
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Reply Packets sent in response to a single Request VCP Feature Packet starts at zero and 
increments by one. The last VCP Feature List. Item in the last VCP Feature Reply Packet 
should contain an MCCS VCP Control Code value equal to Oxffff to identify that the packet 
is the last one and contains the highest sequence number of the group of packets returned, 
If only one VCP Feature Reply Packet is sent in response to a Request VCP Feature Packet 
then the Reply Sequence Number in that single packet is zero and the VCP Feature Reply 
List contains a record having an MCCS VCP Control Code equal to Oxffff. 
[00279] The Number of Features in List field contains- 2 bytes that specifies the number of 

VCP Feature List Items that are in the VCP Feature Reply List in this packet, while the 
VCP .Feature Reply List field is a a group of bytes that contain one or more VCP Feature 
Reply List Items. The format of a single VCP Feature Reply List Item in one embodiment 
is shown in FIG. 71. 

[00280] As shown in FIG. 71, each VCP Feature Reply List Item is exactly 12 bytes in 
length, and comprises the MCCS VCP Code, Result Code, Maximum Value, and Present 
Value fields. The 2-byte MCCS VCP Code field contains data or infomraitn that specifies 
the MCCS VCP Control Code Parameter associated with this list item. Only the Control 
Code values defined in the VESA MCCS Specification version 2 and later are considered as 
valid. The 2-byte Result Code field contains information that specifies an error code related 
to the request for information regarding the specified MCCS VCP Control. A value of '0' 
in this field means there is no error, while a value of '1' means the specified control is not 
implemented in the client. Further values for this field of 2 through 65535 are currently 
reserved for future use and implementation of other application contemplated by the art, but 
are not to be used for now. 

[00281] The 4-byte Maximum Value- field contains a 32-bit unsigned integer that specifies 

the largest possible value to which the specified MCCS Control can be set. If the requested 
control is not implemented in the client this value is set to zero; If the value returned is less 
than 32 bits (4 bytes) in length, then the value is cast into a 32-bit integer leaving the most 
significant (unused) bytes set to zero. The 4-byte Present Value field contains information 
that specifies the present- value of the specified MCCS VCP Continuous (C) or non- 
continuous (NC) control. If the requested control is not implemented in the client or if the 
control is implemented but is a table (T) data type, then this- value is set to zero. If the value 
returned is less than 32 bits (4 -bytes) in length per fee VESA MCCS specification then the 
value is cast into a 32-bit integer leaving. the most significant (unused) bytes set to zero. 
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29. Set VCP Feature Packet 

[00282] The Set VCP Feature Packet provides a means, mechanism, or method for a host to 

set VCP control values for both continuous and non-eontinuous controls in a client. In one 
embodiment, the client indicates the ability to support the Set VCP Feature Packet using bit 
20 of the Display Feature Capability Indicators field of the Display Capability Packet. 

[00283] The format of the Set VCP Feature Packet in one embodiment is shown in FIG. 72. 

As seen in PEG. 7:2, this type of packet is structured to have Packet Length, Packet Type, 
hCJient ID, MCCS VCP Code, Number of VLaues in List, Control Value List, and CRC 
fields. This type of packet is generally identified as a Type 130, as indicated in the 2 byte 
type field, is 20 bytes long exclusive of the Packet Length field. 

[00284] The hClient ID field again uses a 2-byte value to specify or act as a Client ID. This 
field is reserved for future use and is currently set to zero. The MCCS VCP Code field uses 
2 bytes of information or values to specify the MCCS VCP Control Code Parameter to be 
adjusted. The 2-byte Number of Values in List Field contains information or values that 
specifies the number of 16-bit values that exist in the Control Value List. The Control 
Value List will usually contain one item unless the MCCS Control Code relates to a table in 
the client. In the case of non-table-related controls, The Control Value List will contain a 
value that specifies the new value to be written to the control parameter specified by the 
MCCS VCP Code field. For table-related controls the format of the data in the Control 
Value List is specified by the parameter description of the specified MCCS VCP Code. If 
the list contains values that are larger than one byte, then the least-significant byte is 
transmitted first, consistent with the method defined elsewhere. Finally, the 2-byte CRC 
field contains a 16 bit CRC of all bytes in the packet including the Packet Length. 

30. Request Valid Parameter Packet 

.00285] The Request Valid Parameter Packet is used as a means or mechanism to request 

that a client return a Valid Parameter Reply Packet containing a list of parameters supported 
by the specified non-continuous (NC) or table (T) control. This packet should only specify 
non-continuous controls or controls that relate to .a table in the client, and not specify a 
MCCS. VCP Code value of 6553.5 (Oxffff) to specify all controls. If a non-supported or 
invalid MCCS VCP Code is specified then an appropriate error value is returned in the 
Valid Parameter Reply Packet. In one embodiment, the client indicates an ability to support 
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the Request Valid Parameter Packet using bit 20 of the. Display Feature .Capability 
Indicators field of (lie Display Capability Packet. 

[00286] The format of the Request Valid Parameter Packet in one embodiment is shown in 

PIG, 73. As seen in FIG. 73, this type of packet is structured to have Packet Length, Packet 
Type, hCJient ID, MCCS VCP Code, and CRC fields. This type of packet is generally 
identified in one embodiment as a Type 131, as indicated in the 2 byte type field. 

[00287] The packet length, as indicated in the 2-bytes Packet Length Field is generally set to 

have a total number of bytes in the packet, not including the packet length field of 8. The 
hClient ID again specifies the Client ID, but is currently reserved for future use, as would 
be apparent to one skilled in the art, and is set to zero. The 2-bytc MCCS VCP Code Filed 
contains a value that specifies the non-continuous MCCS VCP Control Code Parameter to 
be. queried. The value in this field should correspond to a non-continuous control that is 
implemented in the client. The values 256 through 65535 (Qxffff) are typically reserved or 
considered as invalid, and are considered as an unimplemented control in the error 
response. 



31. Valid Parameter Reply Packet 

[00288] A Valid Parameter Reply Packet is sent in response to a Request Valid Parameter 

Packet. It is used as a means, method, or mechanism to identify the valid settings for a non- 
continuous MCCS VCP control or a control that returns the contents of a table. If the 
control relates to a table in the client, then the VCP Parameter Reply List simply contains 
the specific list of sequential table values that were requested. If the contents of the table 
cannot fit into a single Valid Parameter Reply Packet then multiple packets with sequential 
Reply Sequence Numbers can be sent by the client. In one embodiment, a client indicates 
an ability to support a Valid Parameter Reply Packet using bit 20 of the Display Feature 
Capability Indicators field of the Display Capability Packet, 

[00289] A host may request the contents of a table in the following manner: the host sends a 

Set VCP Feature Packet containing the necessary or desired parameters such as read/write 
parameter, LUT offset, and RGB selection; then a Request Valid Parameter Packet that 
specifies the desired control is sent by the. host; then the client returns one or mere Valid 
Parameter Reply Packets containing the table data. This sequence of operations- performs a 
similar function as the table reading functions described in the MCCS operation model. 
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[00290] If a specific client parameter is not supported by the client then in one embodiment 

the corresponding field of this packet will contain a value of 255, For parameters that are 
used in the client, the corresponding field should contain a value of the parameter in the 
client. 

[0O291] The format of the Valid Parameter Reply Packet for one embodiment is shown in 

FIG. 74. As seen in FIG. 74, this type of packet is structured to have Packet Length, Packet 
Type, cClient ID, MCCS VCP Code, Response Code, Reply Sequence Number, Number 
Values in List, VCP Parameter Reply List, and CRC fields. This type of packet is generally 
identified for one embodiment as a Type 132, as indicated in the 2 byte type field. 

[00292] The cClient ID field is reserved for the future Client ID, as is known from the above 

discussions, while the 3 -byte MCCS VCP Code Packet contains a value that specifies a 
non-continuous MCCS VCP Control Code Parameter that, is described by this packet. If an 
invalid MCCS VCP Control Code is specified by a Request Valid Parameter Packet, then 
the same invalid parameter value will be specified in this field with the appropriate value in 
the Response Code field. If the MCCS Control Code is invalid then the VCP Parameter 
Reply List will have zero length. 

[00293] The Response Code field contains 2 bytes of information or values that specify the 
nature of the response related to the request for information regarding the specified MCCS 
VCP Control. If the value in this field is equal to 0, then no error is considered as being 
present for this data type, and the last Valid Parameter Reply Packet in the sequence is sent, 
it having the highest Reply Sequence Number. If the value in this field is equal to 1, then 
no error is considered as being present, but other Valid Parameter Reply Packets will be 
sens, that have higher sequence numbers. If the value in this field is equal to 2, then the 
specified control is not considered as being, implemented in the client. If the value in this 
field id equal to 3, then the specified control is not a non-continuous control (it is a 
continuous control that always has a valid set of all values from zero to its maximum 
value). Values for this field equal to 4 through 65535 are reserved for future use and 
generally not to be used. 

[00294] The 2-bytc Reply Sequence Number field specifies: the sequence number of hie 

Valid Parameter Reply Packets returned by the client. The client returns one or more Valid 
Parameter Reply Packets in response to a Request Valid Parameter Packet. The. client may- 
spread: the VCP Parameter Reply list over multiple Valid Parameter Reply Packets. In this 
latter case, the client will assign a sequence number to each successive packet, and set the 
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Response Code to 1 in all 'but the last packet in the sequence. The last Valid Parameter 
Reply Packet in the sequence will have the highest Reply Sequence Number and the. 
Response Code contains a value of 0. 
[00295] The 2-byte Number of Values in List field specifies the number of 16-bit values that 
exist in the VCP Parameter Reply list. If the Response Code is not equal to zero then the 
Number of Values in List parameter is zero. The VCP Parameter Reply List, field contains 
a list of 0 to 32760- 2-byte values that indicate the set of valid values for the non-continuous 
control specified by the MCCS Control Code field. The definitions of the non-continuous 
control codes are specified in the VESA MCCS Specification. Finally, in this embodiment, 
the CRC field contains a 16-bit CRC of all bytes in the packet including the Packet Length. 

Alpha-Cursor Images 

[00296] The MOD interface and associate inventive protocol and mechanisms for 
communicating data oyer a communications link provides support for multiple image 
planes that overlap each other and can have varying degrees of transparency. A hardware 
cursor can be implemented using an overlapping image that has a variable X~Y offset. An 
overview of the Alpha-Cursor functionality and associated protocol support is provided 
below. The ability to support Alpha-Cursor image packets is defined in the Alpha-Cursor 
Image Capability Packet, which is sent in response to a Request Specific Status Packet, 

32. A Ipha-Curmr Image Capability Packet 

[00297] The Alpha-Cursor Image Capability Packet is used to define the characteristics of 
the alpha-cursor image and associated transparency maps in a client. In one embodiment, a 
client indicates an ability to support an Alpha-Cursor Image Capability Packet using a 
parameter value of 133 in the Valid Parameter Reply List of the Valid Status Reply List 
Packet. The packet length specified in the packet length field is set to a fixed, value of 20 
for one embodiment, not including the packet length field. 

[002981 The format of the Alpha-Cursor Image Capability Packet for one embodiment is 
shown in FIG. 75, As seen in FIG. 75, this type of packet is structured to have Packet 
Length, Packet Type, cClient ID, Alpha-Cursor Identifier, Alpha-Cursor Bitmap Width, 
Alpha-Cursor Bitmap Height, RGB Capability, Monochrome Capability, Reserved 1, Y Gr 
Cb Capability, Transparency Map Res., Capability Bits, and CRC fields. The cClient ID 
field is typically reserved for future Client ID use and currently set to zero. 
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[00299] The Alpha Cursor Identifier field (2 bytes) contains a value that identifies, a specific 

alpha-cursor plane. If the client supports n alpha-cursor image planes then the Alpha- 
Cursor Identifier has a valid range of 0 to n - 1. In one embodiment, ihe value n is specified 
by the Alpha-Cursor Image Planes field of the Display Capability Packet. The client 
returns a unique Alpha-Cursor Image Capability Packet for each alpha-cursor image plane. 

[00300] The 2-byte Alpha-Cursor Bitmap Width field value specifies the width of the alpha- 
cursor bitmap image expressed as a number of pixels, while die 2-byte Alpha-Cursor 
Bitmap Height field value specifies the height of the alpha-cursor bitmap image expressed 
as a number of pixels. 

[00301] The RGB Capability field - 2 bytes that contain a 16-bit unsigned integer that 
specifies the number of bits of resolution that can be displayed in RGB format. If the clien t 
cannot use the RGB format then this value is zero. The RGB Capability word is composed 
of three separate values, which in one embodiment are implemented such that: Bits 3 
through 0 define the maximum number of bits of blue (the blue intensity) in each pixel; Bits 
7 through 4 define the maximum number of bits of green (the green intensity) in each 
pixel; Bits 11 through 8 define the maximum number of bits of red (the red intensity) in 
each pixel; with Bits 15 through 12 being reserved for future use in presenting RGB 
capability information and are set to zero for now. 

[00302] The 1-byte Monochrome Capability field is used to specify the number of bits of 
resolution that can be displayed in monochrome format. If a client cannot use the 
monochrome format then this value is zero. Bits 7 through 4 are reserved for future use and 
are, therefore, generally set to zero. Bits 3 through 0 define the maximum number of bits of 
grayscale that can exist in each pixel. These four bits make it possible to specify that each 
pixel consists of 1 to 15 bits. If the value is zero then the monochrome format is not 
supported by the client, 

[00303] The 1-byte Reserved 1 field contains a value generally reserved for future use, and 
as such all bits in this field are set to zero. This will cause subsequent 2-byte fields to alien 
to a 16-bit word address and cause 4-byte fields to align to a 32-bit word address, 

[003G4J The 2-byte Y Cb Cr Capability field contains values or information that specifies the 

number of bits of resolution that can be displayed in Y Cb Cr format. If the client cannot 
use the Y Cr Cb format then this value is zero. Generally, in one embodiment, the Y Cb Cr 
Capability word is composed of three separate values with: Bits 3 through 0 defining a 
maximum number of bits that specify the Cr sample; Bits 7 through 4 defining the 
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maximum number of bits that specify the Cb sample; Bits 11 through 8 defining the 
maximum number of bits that specif],' the Y sample; and with Bits 15 through 12 being 
reserved for future use in presenting Y Cb Cr Capability information or values, but 
currently being set to zero. 

[00305] The 1 byte Transparency Map Resolution field contains values or information that 

specifies the number of bits (depth) in each pixel location of the alpha-cursor image 
transparency map. This value may range from 1 to 8, If the value is zero then the 
transparency map is not supported for this alpha-cursor image buffer (the buffer specified 
by the Alpha-Cursor Identifier Field). 

[00306] The 1-hyte Capability Bits field provides values or information that contains a set of 

flags that specify capabilities associated with the alpha-cursor image buffer. In one 
embodiment, the flags are defined such that: Bit 0 acts to select Pixel data in the alpha- 
Cursor Video Stream Packet to be in a packed format. Bit 1 acts to show that transparency 
map data in the Alpha-Cursor Transparency Packet is in a packet format. An example of 
byte-aligned, and packed transparency map data is shown in FIG. 76. Bit 2 acts to show that 
the alpha-cursor image plane supports image offset capability using the Alpha-Cursor 
Image Offset Packet. Bit 3 acts to show that the alpha-cursor image plane can support a 
color map data format. The same color map table is used for the alpha-cursor image planes 
as is used for the main image buffer and scaled video streams. The color map is configured 
using the Color Map Packet described elsewhere. 

[00307] Bits 7 through 4 are reserved for future use and are generally, therefore, set to a zero 

value or logic level. 

33, Alpha-Cursor Transparency Map Packet 
[00308] The Alpha-Cursor Transparency Map Packet defines the contents of the image 

transparency map for the specified alpha-cursor image plane. Some applications may 
require a transparency map that is larger than the amount of data that can be transmitted In a 
single packet, hi these cases, multiple Alpha-Cursor Transparency Map Packets may be 
sent, each with a different subset of the transparency map by using the Transparency Map X 
and Y Start fields described below. These fields operate in a similar manner as the X Start 
and Y Start fields of the Video Stream Packet. A client indicates an ability to support the 
Alpha-Cursor Transparency Map Packet in one embodiment using the Transparency Map 
Resolution field of the Alpha-Cursor Image Capability Packet for each specific Alpha- 
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Cursor Plane specified by the Alpha-Cursor Identifier field of the Alpha-Cursor Image 
Capability Packet. The packet length and Client ID fields operate as before for other 
packets discussed above. In one embodiment, a value of 134 in the Packet Type field is. 
used to identify a packet as a Alpha-Cursor Transparency Map Packet. 

[003O9J The format of the Alpha-Cursor Transparency Map Packet for one embodiment is 

shown in FIG. 76. As seen in FIG. 76, this type of packet is structured to have Packet 
Length, Packet Type, hClient ID, Alpha-Cursor Identifier, Transparency Map X Start, 
Transparency Map Y Start, Transparency Map Resolution, Reserved 1, Parameter CRC, 
Transparency Map Media, and Transparency Map Data CRC fields. 

[003 101 The 2-byte Alpha Cursor Identifier field has a value that identifies a specific alpha- 

cursor plane. If the client supports n alpha-cursor image planes then the Alpha-Cursor 
Identifier has a valid range of 0 to n - 1. 

[0031 1] The 2-byte Transparency Map X and Y Start fields each specify the absolute X and 
Y coordinates, where the point (Transparency Map X Start, Transparency Map Y Start) is 
the first pixel in the Transparency Map Data field below. 

[00312] The transparency Map Resolution field {1 byte) contains a value that specifies the 
resolution of the transparency map and whether or not the data is packed. In one 
embodiment of this field, Bits 3 through 0 define the number of bits of resolution that exist 
in all transparency map table items. Valid values specify the width to be from 1 to 8 bits. 
Values 0 and 9 through 15 are considered invalid. This value should match the value 
returned by a client in the Transparency Map Resolution field in the Alpha-Cursor Image 
Capability Packet Bite 6 through 4 are reserved for future use and are, therefore, generally 
shall be set to logic-zero at this time. Bit 7 of this byte specifies whether or not the 
Transparency Map Data is in packed or byte-aligned form. If bit 7 is equal to '1* then the 
Transparency Map Data is in packed form, and if '0' the data is byte-aligned. An example 
of packed and byte-aligned Transparency Map data is- shown in Error! Reference source 
not found.. The value of this bit must match the value of bit I of the Capability Bits field 
of the Alpha-Cursor Image Capability Packet. 

[00313] The 1 bute Reserved. 1 field is reserved for .future use, therefore, all bits in this, field 

are generally set equal to a logic-zero level. One purpose of this field is to cause all 
subsequent 2 byte fields to align to a 16-bit word address and cause 4-byte fields to align to 
a 32-bit word address. 
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[00314] The Parameter CRC field contain a 16-bit CRC of all bytes from the Packet Length 

to the Reserved 1 field. If this CRC fails to check then the entire packet is to be discarded. 

[003 1 5] For the Transparency Map Data fields each transparency map location is 1 to 8 bits 

in width. If a single transparency map cannot fit into one Alpha and Cursor Transparency 
Map Packet, then the entire transparency map may be specified by sending multiple packets 
with different Transparency Map Data and Transparency Map X and Y Start values in each 
packet. 

[00316] The 2-byte Transparency Map Data CRC field contains a 16-bit CRC of only the 

Transparency Map Data. If this CRC fails to check then the Transparency Map Data can 
still be used but the CRC error count shall be incremented 



34. Alpha-Cursor Image Offset Packet 

[00317] The Alpha-Cursor Image Offset Packet specifies the X and Y offset of the cursor 
from the upper left corner of the main display image. The format of the Alpha-Cursor 
Image Offset Packet is illustrated in FIG. 77. As shown in FIG. 77, in one embodiment, the 
Alpha-Cursor Image Offset Packet is structured with Packet Length, Packet Type, hClient 
ID:, Alpha-Cursor X Offset, Alpha-Cursor Y Offset, and CRC fields. In one embodiment, a 
client indicates the ability to support the Alpha-Cursor Image Offset Packet using bit 2 of 
the Capability Bits field of the Alpha-Cursor Image Capability Packet for each specific 
Alpha-Cursor Plane specified by the Alpha-Cursor Identifier field of the Alpha-Cursor 
Image Capability Packet. In one embodiment, the packet length is fixed at 10, as shown in 
the 2-byte Packet Length field. In one embodiment, a Packet Type of 135 identifies the 
packet, as an Alpha-Cursor Image Offset Packet. 

{00318] The 2-byte Alpha-Cursor X and Y Offset fields contain values that specify the 

horizontal and vertical, respectively, offset of the left-most column and top row, 
respectively of pixels of the cursor image from the left side and top of the main image. The 
hClient ID - 2 bytes that contain a 16-bit unsigned integer reserved for the Client ID. This 
field is reserved for future use and shall be set to zero. 



35. Alpfia-Cursor Video Stream Packet 

[00319] The Alpha-Cursor Video Stream Packet carries video data to update a rectangular 

region of an alpha-cursor image plane. The size of this region may be as small as a single 
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pixel or as large as the entire display. The format of trie Alpha-Cursor Video Stream Packet 
is illustrated in FIG. 78, As shown in FIG 78, in one embodiment the Alpha-Cursor Video 
Stream Packet is structured with Packet Length, Packet Type, bCIient ID, Video Data 
Format Attributes, X Left Edge, Y Top Edge, X Rigth Edge, Y Bottom Edge, X Start, Y 
Start, Pixel Count, Parameter Crc Pixel Data, and Pixel Data CRC fields. In one 
embodiment, a client indicates an ability to support the Alpha-Cursor Video S tream Packet 
and its associated parameters by using the Alpha-Cursor Image Capability Packet for each 
specific Alpha-Cursor Plane specified by the Alpha-Cursor Identifier field of the Alpha- 
Cursor Image Capability Packet, and a value of 17 in the packet type field indicates or 
identifies a packet as being an Alpha-Cursor Video Stream Packet. The hClient ID field (2 
bytes) is reserved for future use as a Client ID, and is generally set to zero in the meantime, 
as would he well understood in the art. 

(00320J The 2-bytc Video Data Format Descriptor field contains information or a value that 
specifies the format of each pixel in the Pixel Data in the present stream in the present 
packet. The pixel data format must comply with at least one of the valid formats for the 
alpha-cursor image plane as defined in the Alpha-Cursor Image Capability Packet. The 
Video Data Format Descriptor field contains a value that defines the pixel format for the 
current packet only and does not imply that a constant format will continue to be used for 
the lifetime of a particular video stream. Error! Reference source hot found, illustrates 
how the Video Data Format Descriptor is coded. The format is as follows: 

[00321] In one embodiment, when bits [15:13] are '000' then the video data consists of an 
array of monochrome pixels where the number of bits per pixel is defined by bits 3 through 
0 of the Video Data Format Descriptor word. Bits 11 through 4 are then set to zero. When 
bits [15:13] are 'OOF then the video data consists of an array of color pixels that each 
specify a color through a color map (palette). Bits 5 through 0 of the Video Data Format 
Descriptor word define the number of bits per pixel, and Bits 11 through 6 are set to zero. 
When bits [15:13] are '010' then the video data consists of an array of color pixels in raw 
RGB format where the number of bits per pixel of red is defined by bits 1 1 through 8, the 
number of bits per pixel of green is defined by bits 7 through 4, and the number of bits per 
pixel of blue is defined by bits 3 through 0:. The total number of bits in each pixel is the 
sum of the number of bits used for red, green, and blue, 

[00322] When bits [15:13] are 'Oil' then the video data consists of an array of video data in 

4:2:2 Y Cb Cr format with luminance, and chrominance information. The number of bits 
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per pixel of luminance (Y) is defined by- bits 11 through S, the. number of bits of the Cb 
component is defined by bits 7 through 4, and the number of bits of the Cr component is 
defined by bits 3 through 0. The Cb and Cr components are sent at half the rate as Y. The 
video samples in the Pixel Data portion of this packet will be organized as follows: Cbn, 
Yn, Cm, Yn+I, Cbn+2, Yn+2, Cm+2, Yn+3, ... -where Cbn and Cm are associated with Yn 
and Yn+I, and Cbn+2 and Cm+2 are associated with Yn+2 and Yn+3, and so on, Yn, 
Yn+1 , Yn+2 and Yn+3 are luminance values of four consecutive pixels in a single row 
from left to right. The ordering of the color components is the same as the Microsoft 
UYVY FOURCC format. If there are an odd number of pixels in a row (X Might Edge - X 
Left Edge + 1) in the window referenced by the Video Stream Packet then the Cb value 
corresponding to the last pixel in each row will be followed by the Y value of the first pixel 
of the next row. It is recommended that windows using Y Cb Cr format have a width that is 
an even number of pixels: The Pixel Data in a packet shall contain an even number of 
pixels. It may contain an odd or even number of pixels in the case where the last pixel of 
the Pixel Data corresponds to the last pixel of a row in the window specified in the Video 
Stream Packet header, i.e. when the X location of the last pixel in the Pixel Data is equal to 
X Right Edge. For all four formats, bit 12 (designated as "P" in the figures) specifies 
whether or not the Pixel Data samples are packed. When the value of bit 12 is '0' then each 
pixel and each color within each pixel in the Pixel Data field is byte-aligned with an MDDI 
interface byte boundary. When the value of bit 12 is T then each pixel and each color 
within each pixel in the Pixel Data is packed up against the previous pixel or color within a 
pixel leaving no unused bits. 

[00323] In one embodiment, the Pixel Data Attributes field (2 byte) has a series of bit values 

that are interpreted as follows. Bits 1 and 0 select how the display pixel data is routed. For 
bit values of '11' data is displayed to or for both eyes, for bit values 10', data is routed only 
to the left eye, and for bit values- '01 ', data is routed only to the right eye. 

[00324] Bit 2 indicates whether or not the Pixel Data is presented in an interlace format, with 

a value of '0' meaning the pixel data is in the standard progressive format, and that the row 
number (pixel Y coordinate) is incremented by 1 when advancing from one row to the next. 
When this bit has a value of T, the pixel data is in interlace format, and the row number is 
incremented by 2 when advancing from one row to the next. Bit 3 indicates that the Pixel 
Data is in alternate pixel format. This is similar to the standard interlace mode enabled by 
bit 2, but the interlacing is vertical instead of horizontal. When Bit 3 is '0* the Pixel Data is 
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in the standard progressive format, and the column number (pixel X coordinate) is 
incremented by 1 as each, successive pixel is received. When Bit 3 is 'V the Pixel Data is 
in alternate pixel format, and the column number is incremented by 2 as each pixel is 
received. 

[00325] Bit 4 indicates whether or not the- Pixel data is related to a display or a camera, as 

where data is being transferred to or from an internal display for a wireless phone or similar 
device or even a portable computer, or such other devices as discussed above, or the data is 
being transferred to or from a camera built into or directly coupled to the device. When Bit 
4 is '0' the Pixel data is being transferred to or from a display frame buffer. When Bit 4 is 
'1' Pixel data is being transferred to or from a camera or video device of some type, such 
devices being well known in the art, 

[00326] Bit 5 is reserved for future use or applications of the MDD interface and is, 

therefore, generally set as zero value or '0' . 

[00327] Bits 7 and 6 are Display Update Bits that specify a frame buffer where the pixel data 
is. to be written. The more specific effects are discussed elsewhere. For bit values of l QV 
Pixel data is written to the offline image buffer. For bit values of '00' Pixel data is written 
to the image buffer used to refresh the display. For bit values of '11 ' Pixel data is written to 
all image buffers. The bit values or combination of '10' is treated as an invalid value or 
designation and Pixel data is ignored and not written to any of the image buffers. This 
value may have use for future applications of the interface. 

[00328] Bits 8 through 15 are reserved for future use and are, therefore, generally set as zero. 

[00329] In one embodiment, the 2-byte X Start and Y Start fields specify the absolute X and 

Y coordinates of the point (X Start, Y Start) for the first pixel in the Pixel Data field. The 
2-byte X Left Edge and Y Top Edge fields specify the X coordinate of the left edge and Y 
coordinate of the top edge of the alpha-cursor image window filled by the Pixel Data field, 
while the X Right Edge and Y Bottom Edge fields specify the X coordinate of the right 
edge, and the Y coordinate of the bottom edge of the alpha-cursor image window being 
updated. 

[00330] The Pixel Count field (2 bytes) specifies the number of pixels in the Pixel Data field 

below. 

[0033 1] The 2-byte Parameter CRC field contains a CRC of all bytes from the Packet Length 

to the Pixel Count If this CRC fails to check then the entire packet is discarded. 
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[003321 The Pixel Data field contains the raw video information that is to be displayed, and 

which is formatted in the manner described by the Video Data Format Descriptor field. The 

data is transmitted one "ro w" at a time as discussed elsewhere. 
[00333] The Pixel Data CRC field (2 bytes) contains a 16-bit CRC of only the Pixel Data. If 

a CRC verification of this value fails then the Pixel Data can still be used, but the CRC 

error count is incremented. 



Scaled Video Stream images 
[00334] The MDD Interface or protocol mechanism or method provides support for scaled 

video stream images that allow the host to send an image to the client that is scaled larger or 
smaller than the original image, and the scaled image is copied to a main image buffer. An 
overview of the Scaled Video Stream functionality and associated protocol support is 
provided elsewhere, An ability to support scaled video streams is defined by or within the 
Scaled Video Stream Capability Packet, which is sent in response to a Request Specific 
Status Packet. 



36. Sealed Video Stream Capability Packet 

[00335] The Scaled Video Stream Capability Packet defines the characteristics of the scaled 
video stream source image in or used by a client. The format of the Scaled Video Stream 
Capability Packet is shown generally in FIG. 79. As seen in FIG. 79, in one embodiment, a 
Scaled Video Stream Capability Packet is structured to have Packet Length, Packet Type, 
eClieut ID, Max Number of Streams, Source Max X Size, Source Max Y size, RGB 
Capability, Monochrome Capability, Reserved 1, ¥ Cr Cb Capability, Reserved 2, and CRC 
fields, Thr packet length, in one embodiment, is selected to be a fixed 20 bytes, as shown in 
the length field, including the 2-byte cClient ID field, reserved for use for a Client ID, 
otherwise set to zero, and the .CRC field. In one embodiment, the client indicates an ability 
to support the Scaled Video Stream Capability Packet using a parameter value of 143 in the 
Valid Parameter Reply List of the Valid Status. Reply List Packet. 

[00336] The 2-byte Maximum Number of Streams field contains a value to identify the 

maximum number of simultaneous scaled video streams that may be allocated at one time. 
In one embodiment, a client should deny a request to allocate a scaled video stream if the 
maximum number of scaled video streams are already allocated. If less than the maximum 
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number of scaled video streams are allocated the client may also deny atl allocation request 
based on other resource limitations in the client. 

[00337] The Source Maximum X Size and Y size fields (2 bytes) specify values for the 

maximum width and height, respectively, of the scaled video stream source image 
expressed as a number of pixels. 

[0033 S] The RGB Capability field uses values to specify the number of bits of resolution that 

can be displayed in RGB format. If the scaled video stream cannot use the RGB format 
then this value is set equal to zero. The RGB Capability word is composed of three separate 
unsigned values with; Bits 3 through 0 defining a maximum number of bits of blue (the 
blue intensity) in each pixel, Bits 7 through 4 defining the maximum number of bits of 
green (the green intensity) in each pixel, and Bits 11 through 8 defining the maximum 
number of bits of red (the red intensity) in each pixel, while Bits 15 through 12 are reserved 
for future use in future capability definitions, and are generally set to zero. 

[00339] The 1-byte Monochrome Capability field contains a value that specifies the number 
of bits of resolution that can be displayed in monochrome format. Tf the scaled video 
stream cannot use the monochrome format then this value is zero. Bits 7 through 4 are 
reserved for future use and should, therefore, be set to zero ('0') for current applications, 
although this may change over time, as will be appreciated by those skilled in the art. Bits 3 
through 0 define, the maximum number of bits of grayscale that can exist in each pixel. 
These four bits make it possible to specify that each pixel consists of 1 to 15 bits. If' the 
value is zero, then the monochrome format is not supported by the scaled video stream. 

[00340] The Reserved 1 field (here 1 byte) is reserved for future use in providing values 
related to the Scaled Video Stream Packet information or data. Therefore, currently, all bits 
in this field are set to a logic '0". One purpose of this field is to cause all subsequent 2-byte 
fields to align to a 16-bit word address and cause 4-byte fields to align to a 32-bit word 
address. 

[00341] The 2-byte Y Cb Cr Capability field -contain values that specify the number of bits 

of resolution that can be displayed in Y Cb Cr format. If the scaled video stream cannot use 
the Y Cb Cr format then this value is zero. The Y Cb Cr Capability word is composed of 
three separate unsigned values with: Bits 3 through 0 defining the maximum number of bits 
that specify the Cr sample; Bits 7 through 4 defining the maximum number of bits that 
specify the Cb sample; Bits 11 through 8 defining the maximum number of bits specify the 
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Y sample; and with Bits 15 through 12 being reserved for future use and is generally set to 
.zero. 

[00342] The 1-byte Capability Bits field contains an 8-bit unsigned integer that contains a set 

of flags that specify capabilities associated with the scaled video stream. The flags are 
defined as follows: Bit 0 covers Pixel data in the Scaled Video Stream Packet can be in a 
packed format. An example of packed and byte-aligned pixel data is shown in Error! 
Ii iti reice source not foundUBit 1 is reserved for future use arid shall be set to zero; Bit 2 is 
reserved for future use and shall be set to zero; Bit 3 covers scaled video streams that can be 
specified in the color map data format. The same color map table is used for the scaled 
video streams as is used for the main image buffer and the alpha-cursor image planes. The 
color map is configured using the Color Map Packet described in elsewhere; and Bits 7 
through 4 are reserved for future use and are generally set to be zero. 

[00343] The Reserved 2 field (here 1 byte) is reserved for future use in providing values 
related to the Scaled Video Stream Packet information or data. Therefore, currently, all bits 
in this field are set to a logic '0' . One purpose of this field is to cause all subsequent 2-byte 
fields to align to a 16-bit word address and cause 4-byte fields to align to a 32-bit word 
address. 

57. Scaled Video Stream Setup Packet 

[00344] The Scaled Video Stream Setup Packet is used to define the parameters of the scaled 
video stream and the client uses the information to allocate internal storage for buffering 
and scaling of the image. A stream may be de-allocated by sending this packet with the X 
Image Size and Y Image Size fields equal to 7-ero. Scaled video streams that have been de- 
allocated may be reallocated later with the same or different stream parameters. In one 
embodiment a client indicates an ability to support the Scaled Video Stream Setup Packet 
using a parameter value of 143 in the Valid Parameter Reply List of the Valid Status Reply 
List Packet, and by using a non-zero value in tile Maximum Number of Streams field of the 
Scaled Video Stream Capability Packet. 



[00345] 



Packet definition is illustrated in Error!. Reference source not found.. 
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| X Left Edge | YTop Edgsjx Rig 



2 bytes 2 bytes 2 bytes 2 bytes 2 bytes 2 bytes 2 bytes 

Packet Contents: 

[00346] Packet Length - 2 bytes that contain a 16-bit unsigned integer that specifies the total 

number of bytes in the packet not including the packet length field. The packet length of 
this packet is always 24. 

[00347] Packet Type - 2 bytes that contain a 16-bit unsigned integer. A Packet Type of 136 

identifies the packet as a Scaled Video Stream Setup Packet. 

[00348] hClient ID - 2 bytes that contain a 16-bit unsigned integer reserved for the Client 

ID. This field is reserved for future use and shall be set to zero 

[00349] Stream ID - 2 bytes that contain a 16-bit unsigned integer that specifies a unique 

identifier for the Stream ID. This value is assigned by the host and shall be from zero to the 
maximum Stream ID value specified in the Display Capability Packet. The host must 
manage the use of Stream ID values carefully to ensure that each active stream is assigned a 
unique value, and that streams that are no longer active are deallocated or reassigned. 

[00350] Video Data Format Descriptor - 2 bytes that contain a 16-bit unsigned integer that 

specifies the format of each pixel in the Pixel Data in the present stream in the present 
packet The pixel data format must comply with at least one of the valid formats for the 
alpha-cursor image plane as defined in the Alpha-Cursor Image Capability Packet. The 
Video Data Format Descriptor defines the pixel format for the current packet only and does 
not imply that a constant format will continue to be used for the lifetime of a particular 
video stream. Error! Reference source not found, illustrates how the Video Data Format 
Descriptor is coded. The format is as follows: 

[00351] If hits [15:13] = 000 then the video data consists of an array of monochrome pixels 

where the number of bits per pixel is defined by bits 3 through 0 of the Video Data Format 
Descriptor word. Bits 1 1 through 4 shall be set to zero. 
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[00352] If bits [15: 13] =. 001 then the video data consists of an array of color pixels that each 

specify a color through a color map (palette). Bits 5 through 0 of the Video Data Format 
Descriptor word define the number of bits per pixel. Bits 1 1 through 6 shall be set to zero. 

[00353] If bits [15:13] - 010 then the video data consists of an array of color pixels in raw 

RGB format where the number of bits pear pixel of red is defined by bits 1 1 through 8, the 
number of bits per 

[00354] pixel of green is defined by bits 7 through 4, and the number of bits per pixel of blue 

is defined by bits 3 through 0. The total number of bits in each pixel is the sum of the 
number of bits used for red, green, and blue. 
[00355] [15:13] =011 then the video data consists of an array of video data in 4:2:2 Y Cb Cr 

format with luminance and chrominance information. The number of bits per pixel of 
luminance (Y) is defined by bits 11 through 8, the number of bits of the Cb component is 
defined by bits 7 through 4, and the number of bits of the Cr component is defined by bits 3 
through 0. The Cb and Cr components are sent at half the rate as Y. The video samples in 
the Pixel Data portion of this packet will be organized as follows:: Cbn, Yn, Cm, Yn+1, 
Cbn+2, Yn+2, Crn+2, Yn+3, . . . where Cbn and Cm are associated with Yn and Yn+1, and 
Cbn+2 and Crn+2 are associated with Yn+2 and Yn+3, and so on. Yn, Yn+1, Yn+2 and 
Yn+3 are luminance values of four consecutive pixels in a single row from left to right. 
The ordering of the color components is the same as the Microsoft UYVY FOURCC 
format. If there arc an odd number of pixels in a row (X Right Edge - X Left Edge + 1) in 
the window referenced by the Video Stream Packet then the Cb value corresponding to the 
last pixel in each row will be followed by the Y value of the first pixel of the next row. It is 
recommended that windows using Y Cb Cr format have a width that is an even number of 
pixels. The Pixel. Data in a packet shall contain an even number of pixels. It may contain 
an odd or even number of pixels in the case where the last pixel of the Pixel Data 
corresponds to the last pixel of a row in the window specified in the Video Stream Packet 
header, j.e. when the X location of the last pixel in the Pixel Data is equal to X Right Edge. 

[00356] For all four formats bit 12 (designated as iS P" in Error! Reference source not 

found.) specifies whether or not the Pixel Data samples are packed. Error! Reference 
source not found, illustrates the difference between packed and byte-aligned pixel data. 

[00357] 0 - each pixel and each color within each pixel in the Pixel Data field is byte- 

aligned with an MDDI interface byte boundary, 
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[00358] 1 - each pixel' and each color within each pixel in the Pixel Data is packed up 

against the previous pixel or color within a pixel leaving no unused bits. 

[00359] Pixel Data Attributes - "2 bytes that contain a 16-bit unsigned integer interpreted as 

follows: 

[00360] ' Bits 1 and 0 select the display where the pixel data shall be routed. 
[00361] Bits [1 :01 = 1 1 or 00 - data is displayed to both eyes 
[00362j Bits [1 :0] = 10 - data is routed to the left eye only. 

[00363] Bits [1:0] = 0 1 - data is routed to the right eye only. 

[00364] Bit 2 indicates that the Pixel Data is in interlace format. 

[00365] Bit 2 is 0 - Pixel Data is in the standard progressive format. The row number (pixel 

Y coordinate) shall be incremented by 1 when advancing from one row to the next. 
[00366] Bit 2 is 1 - Pixel Data is in interlace format. The row number (pixel Y coordinate) 

shall be incremented by 2 when advancing from one row to the next. 
[00367] Bit 3 indicates that the Pixel Data is in alternate pixel format. This is similar to the 

standard interlace mode enabled by bit 2, but the interlacing is vertical instead of horizontal. 
(00368] Bit 3 is 0 - Pixel Data is in the standard progressive format. The column number 

(pixel X coordinate) shall be incremented by 1 as each successive pixel is received. 
[00369] Bit 3 is 1 - Pixel Data is in alternate pixel format. The column number (pixel X 

coordinate) shall be incremented by 2 as each pixel is received. 
[00370] Bit 4 indicates whether the Pixel data is related to die display ox the camera. 
[0037 1] Bit 4 is 0 - Pixel Data is to or from the display frame buffer. 

[00372] Bit 4 is 1 - Pixel Data is to or from the camera. 

[00373] Bit 5 is reserved for future use and shall be set to zero. 

[00374] Bits 7 and 6 are the Display Update Bite that specify the frame buffer where the 
pixel data shall be written. The effects of the Frame Update Bits are described in more 
detail in sections Error! Reference source not found, and Error! Reference, source not 
found,. 

[00375] Bits [7:6] = 01 - Pixel data is written to the offline image buffer. 

[00376] Bits [7:6] - 00- Pixel data is written to the image buffer used to refresh the display. 

[00377] Bits [7:6] = 11- Pixel data is written to all image buffers, 

[00378] Bits [7:6] = 10 - Invalid Reserved for future use. Pixel data is ignored and, not 

written to any of the image buffers. 
[00379] Bits 8 through 15 are reserved for future use and shall be. set to zero. 
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[00380] X Left Edge - 2 bytes that contain a 16 bit unsigned integer that specifies the X 

coordinate of the left edge of the destination image. 
[003:811 Y Top Edge - 2 bytes that contain a 16-bit unsigned integer that specifies the Y 

coordinate of the top edge of the destination image. 
[00382] X Right Edge - 2 bytes that contain a 16-bit unsigned integer that specifies the X 

coordinate of the light edge of the destination image. 
[00383] Y Bottom Edge - 2 bytes that contain a 16-bit unsigned integer that specifies the Y 

coordinate of the bottom edge of the destination image. 
[00384] X Image Size - 2 bytes that contain a 16-bit unsigned integer that specifies the 

width of the source image. 
100385] Y image Size - 2 bytes that contain a 16-bit unsigned integer that specifies the 

height of the source image. 
[00386] CRC - 2 bytes that contain a 16-bit CRC of all bytes in the packet including the 

Packet Length. 

Scaled Video Stream Acknowledgement Packet 

[00387] The Scaled Video Stream Acknowledgement Packet allows a client to acknowledge 
the receipt of a Scaled Video Stream Setup Packet. The client shall indicate its ability to 
support the Scaled Video Stream Acknowledgement Packet via a parameter value of 143 in 
the Valid Parameter Reply List of the Valid Status Reply List Packet and via a non-zero 
value in the Maximum Number of Steams field of the Scaled Video Stream Capability 
Packet. 

[00388] Packet definition is illustrated in. 

Scaled Video Stream Acknowledgement Packet 

I tenS | Pa t e i37 YPC l cGiientiP | Stream IP | Ack Codsj" - j 
2 bytes 2 bytes 2 bytes 2 bytes 2 bytes 2 bytes 



Packet Contents: 

[003S9] Packet Length - 2 bytes that contain a 16-bit unsigned integer that specifies the total 

number of bytes in the packet not including, the packet length field. The packet length of 
this packet is always 10. 
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[00390J Packet Type -A Packet Type of 137 identifies the packet as a Scaled Video Stream 

Acknowledgement Packet. 
[00391] cClient ID - 2 bytes that contain a 16-bit unsigned integer reserved for the Client 

ID, This field is reserved for future use and shall be set to zero. 
[00392] Steam ID - 2 bytes that contain a 16-bit unsigned integer that specifies a unique 

identifier for the Stream ID. This is the same value assigned by the host in the Scaled 

Video Stream Setup Packet. 
[00393] The. 2- byte Ack Code field provides values containing a code that describes the 

outcome of an attempt to update the specified scaled video stream. The codes are defined 

as follows: 



[00394] 


0 


- The stream allocation attempt was successful. 


[00395] 


1 


- the stream de-allocation attempt was successful. 


[00396] 


2 . 


- invalid attempt to allocate a stream ID that; has already been allocated. 


[00397] 




- invalid attempt to de-allocate a stream ID that is already de-allocated. 


[00398] 


4 


- the client does not support scaled video streams 


[00399] 


5- 


- the stream parameters are inconsistent with the capability of the client. 


[00400] 




- stream ID value larger than the maximum value allowed by the client. 


[00401] 


7- 


- insufficient resources available in the client to allocate the specified stream. 


[00402] 


CRC - 2 bytes that contain a 16-bit CRC of all bytes in the packet including the 



Packet Length. 



Scaled Video Stream Packet 

[00403] The Sealed Video Stream Packet is used to transmit the pixel data associated with a 
specific scaled video stream. The size of the region reference by this packet is defined by 
the Scaled Video Stream Setup Packet. The client shall indicate its ability to support the 
Scaled Video Stream Packet via a parameter value of 143 in the Valid Parameter Reply List 
of the Valid Status Reply List Packet: and via a successful scaled video stream allocation 
response in the Ack Code field of the Scaled Video Stream Acknowledgement Packet. 

[00404] The packet definition is illustrated in Figure -L 

Scaled Video Stream Packet 

1 LI j -V", ■ 1 a » 1 r c C Lrt Ca, | ™ 1 

■2 bytes Zbyfes 2 bytes 2 bytes 2 bytes 2tytes Packet Length - MBytes 2 bytes 
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Figure -1, Scaled Video Stream Packet 

Packet Contents: 

[00405] Packet.Length - 2 bytes that contain a 16-bit unsigned integer that specifies the total 

number of bytes in the packet not including the packet length field. 
[00406] Packet Type - 2 bytes that contain a 16-bit unsigned integer. A Packet Type of 18 

identifies the packet as a Scaled Video Stream Packet. 
I0OJ07] hClient ID - 2 bytes that contain a 16-bit unsigned integer reserved for the Client 

ID. This field is reserved for future use and shall be set to zero 
[00408] Stream ID - 2 bytes that contain a 16-bit Unsigned integer that specifies a unique 

identifier for the Stream ID. This value is specified by the host in the Sealed Video Stream 

Setup Packet and confirmed in the Scaled Video Stream Acknowledgement Packet. 
[00409] Pixel Count - 2 bytes that contain a 16-bit unsigned integer that specifies the 

number of pixels in the Pixel Data field below. 
[00410] Parameter CRC - 2 bytes that contain a 16-bit CRC of all bytes from the Packet 

Length to the Pixel Count. If this CRC fails to check then the entire packet shall be 

discarded. 

[00411] Pixel Data - The raw video information to be scaled and then displayed. Data, is 

formatted in the manner described by the Video Data Format Descriptor field, The data is 
transmitted a row at a time as defined in section Error! Reference source not found.. 

[00412] Pixel Data CRC - 2 bytes that contain a 16-bit CRC of only the Pixel Data. If this 

CRC fails to check then the Pixel Data shall still be used but the CRC error count shall be 
incremented. 

Request S;m (fit M,«t^ Vm ket 

[00413] The Request Specific Status Packet provides a means for the; host to request that the 

client send a capability or status packet back to host as specified in this packet. The client 
shall return the packet of the specified type in the next Reverse link Encapsulation Packet. 
The client will set bit 17 in the Display Feature Capability Indicators field of the Display 
Capability Packet if- the client has the capabihty to respond to the Request Specific Status 
Packet. The client shall indicate its ability to support the Request Specific Status: Paeket via 
bit 21 of Display Feature Capability Indicators field of the Display Capability Paeket, 
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Request Specific Status Packet 



Packet 
Length 


Packet Type 
= 138 ' 


hClient ID 


Status 
Packet I D 


CRC 


2 bytes 


2 bytes 


2 bytes 


2 bytes 


2 bytes 



Figure, Request Specific Status f^rktf. 
Packet Contents: 

[00414] Packet Length - 2 bytes that contain a 16-bit unsigned integer that specifies the total 

number of bytes in the packet, not including the packet length field. The Packet Length of 
this packet is always .10. 

[00415] Packet "type - 2 bytes that contain a 16-bit unsigned integer. A Packet Type of 138 

identifies the packet as a Request Specific Status Packet. 
[00416] hClient ID - 2 bytes that contain a 16-bit unsigned integer reserved for the Client 

ID. This field is reserved for future use and shall be set to aero. 
[00417] Status Packet ID - 2 bytes that contain a 16-bit unsigned integer that specifies the 

type of capability or status packet that the client shall send to the host as follows: 
[0041S] 66 - Display Capability Packet shall be sent by the client. 

[00419] 133 - Alpha-Cursor Image Capability Packet shall be sent by the client. 

[00420] 139 - Valid Status Reply List Packet shall be sent that identifies the exact types of 

capability and status packets that the client can send. 
[00421] 140 - Packet Processing Delay Parameters Packet shall be sent by the client. 

[00422] 141 - Personal Display Capability Packet shall be sent by the client. 

[00423] 142- Display Error Report Packet shall be sent by the client. 

[00424] 143 - Scaled Video Steam Capability Packet shall be sent by the client. 

[00425] 144 - Display Identification Packet shall be sent by the client. 

[00426] 56 through 63 - can be used for manufacturer-specific capability and status 

identifiers. 

[00427] CRC - 2. bytes that contain a 16-bit CRC of all bytes in the packet including the 

Packet Length. 

Valid Status Reply List Packet 

[00428] The Valid Status Reply List Packet provides the host with a list of status and 

capability packets to which the client has the capability to respond. The client shall indicate 
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its ability to support the Valid Status Reply List Packet via bit 21 of Display Feature 
Capability Indicators field of the Display Capability Packet. 

Valid Status Reply List Packet 

I Packet | Packet Type | , „, f Number of I ., ... _ — 

f Length | = 136 | cCliont :D [vatuw in Ustj VaM Pafam *'*- ^ [ GRC \ 
2 bytes 2 bytes 2 bytes 2 bytes Packet Length - 8 bytes 2 bytes 

Packet Contents: 

[00429] Packet Length - 2 bytes that contain a 16-bit unsigned integer that specifies the total 

number of bytes in the. packet not including the packet length field. The Packet Length of 
this packet .is always 10. 

[00430] Packet Type - 2 bytes that contain a 16-bit unsigned integer. A Packet Type of 1 39 

identifies the packet as a Valid Status Reply Packet 

[00431] cClient LD - 2 bytes that contain a 16-bit unsigned integer reserved for the Client 

ID. This field is reserved for future use and shall be set to zero, 

[00432] Number of Values in List - 2 bytes that contain a 16-bit unsigned integer that 
specifies the number of items in the following Valid Parameter Reply List. 

[00433] Valid Parameter Reply List - a list of 2 byte parameters that specify the types of 

capability or status packets that the client can send to the host. If the client has indicated 
that it can respond to the Request Specific Status Packet (via bit 21 of the Display Feature 
Capability Indicators field the in the Display Capability Packet) then it shall always be 
capable of sending at least the Display Capability Packet (Packet Type ~ 66) and the Valid 
Status Reply List Packet (Packet Type — 139). The Packet Types that maybe included in 
this list and their meaning are: 

[00434] 66 - Display Capability Packet can be sent by the client. 

[00435] 133 - Alpha-Cursor Image Capability Packet can be sent by the client. 

[00436] 139 - Valid Status Reply List Packet can be sent that identifies the exact types of 

capability and status packets that the client can send. 

[00437] 140 - Packet Processing Delay Parameters Packet- can be sent by the client. 

[00438] 141 - Personal Display Capability Packet can be sent by the client. 

[00439] 142 - Display Error Report Packet can be sent by the client. 

[00440] 1 43 - Scaled Video Stream Capability Packet can be sent by the client. 

[0044 1 ] 144- Display Identification Packet can be sent by the client. 
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[00442] 56 through 63 - can be used for manufacturer-specific capability and status 

identifiers. 

[0044-3] CRC - 2 bytes that contain a 16-bit CRC of ail bytes in the packet including the 

Packet Length. 
[00444] Packet Processing Delay Parameters Packet 

100445] The Packet Processing Delay Parameters Packet provides a set of parameters to 

allow the host to compute the time required to complete the processing associated with the 
reception of a specific packet type. Some commands sent by the host cannot be completed 
by the client in zero time. The host may poll the status bits in the Display Request and 
Status Packet to determine if certain functions have been completed by the client, or the 
host may compute the completion time using the parameters returned by the client in the 
Packet Processing Delay Parameters Packet. The client shall indicate its ability to support 
the Packet Processing Delay Parameters Packet via a parameter value of 140 in the Valid 
Parameter Reply List of the Valid Status Reply List Packet. 



Packet Processing Delay Parameters Packet 



1 Packet 
1 l-ength 


Packet Type 
- 140 


cClient ID 


Number of 
List Items 


Delay Parameters List 


CRC 


2 bytes 


2 bytes 


2 bytes 


2 bytes 


Packet Length - 8 bytes 


2- bytes 



Packet Contents: 

[00446] Packet Length - 2 bytes that contain a 16-bit unsigned integer that specifies the total 

number of bytes in the packet not including the packet length field. The Packet Length of 
this packet is always 10. 

[00447] Packet. Type - 2. bytes that contain a 1 6-bit unsigned integer. A Packet Type of 140 

identifies the packet as a Packet Processing Delay Parameters Packet, 
[00448], cClient ID - 2 bytes that contain a 16-bit unsigned integer reserved for the Client 

ID. This field is reserved for future use and shall be set to zero. 
[00449] Number List Items - 2 bytes that contain a 16-bit unsigned integer that specifies the 

number of items in the following Valid Parameter Reply List. 
[00450] Valid Parameter Reply List - a list containing one or more Delay Parameter List 

items. The format of a single Delay Parameters list item is shown in Error! Reference 

source not found,. 



WO 2005/018191 



PC17US2004/026264 



79 

[00451] CRC - 2 bytes that contain a 16-bit. CRC of all bytes in the packet including the 

Packet .Length. 

Delay Parameters List Item 

for Delay | ^ | Pixel Delay j P.xel Defeq F,xed ™* \ 
2 bytes 1 byte 1 byte 1 byte 1 byte 

[00452J Each Delay Parameters List Item is exactly 6 bytes in length, and is defined as 

follows: 

[00453] Packet Type for Delay - 2 bytes that contain a 16-bit unsigned integer that specifies 

the Packet Type- for which the following delay parameters apply. 

[00454] Pixel Delay - 1 byte that contains an 8-bit unsigned integer that is an index to a 

delay value. The value read from the table is multiplied by the total number of pixels in the 
destination field of the packet. The total number of pixels is the width times the height of 
the destination area of the bitmap referenced by the packet. Equation 0-1 is used to compute 
the total delay. 

[004551 Horizontal Pixel Delay - 1 byte that contains an 8-bit unsigned integer that is an 

index to a delay value table (same table as DPVL). The value read from the table is 
multiplied by the width (in pixels) of the destination field of the packet. Equation 0-1 is 
used to compute the total delay. 

[00456] Vertical Pixel Delay - 1 byte that contains an 8-bit unsigned integer that is an index 
to a delay value table (same table as DPVL). The value read from the table is multiplied by 
the height (in pixels) of the destination field of the packet. Equation 0-1 is used to compute 
the total delay. 

[00457] Fixed Delay - 1 byte that contains an 8-bit unsigned integer that is an index to a 

delay value table (same table as DPVL). The value read from the table is a fixed delay 
parameter that represents a time required to process the packet that is unrelated to any 
parameter values specified in the packet.. Equation 0-1 is used to compute the total delay. 



Delay = (PacketProcessingDelay(PixelDelay)-TotalPixels) + 
[00458] (PacketProeessmgDelayCHorizojitalPixelDelay)- Width) + 

[00459] (PacketPtoce.ssingDelay(VerticalPixelDelay)-Height) + 

[0046Q] PacketProcessingDelayOFixedDelay) 
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[00461] Equation 0-L Packet Processing: Completion Time Delay 

[00462] For some packeis the TotaJPixels, Width, or Height do not apply because those 

parameters are not referenced in the corresponding packet. In those cases the corresponding 
Pixel Delay parameter shall be zero. 

Personal Display Capability Packet 

[00463] The Personal Display Capability Packet provides a set of parameters that describe 

the capabilities of a personal display device, such as a head-mounted display or display 
glasses. This enables the host to customize the display information according to the 
specific capabilities of a client. A client, on the other hand, indicates art ability to send the 
Personal Display Capability Packet by using a corresponding parameter in the Valid 
Parameter Reply List of the Valid Status Reply List Packet. 



Personal Display Capability Pacfcet 

I Packet TFa ctePfvFT^TT^ j Sua-Pbtel I p - , T~~ i Hcrzo-fel I Vurtfed I Visual Aids 1 
g LeS 1 =141 l ^ W I Uvoui r TOiShape tFieldofVto|FfeldofWewf Crossing [ 



IUUFW. In 



; »yU> 1 byte 



Packet Contents; 

[00464] Packet Length - 2 bytes that contain a 16-bit unsigned integer that specifies the total 
number of bytes in the packet not including the packet length field. The Packet Length of 
this packet is always 68. 

[00465] Packet Type - 2 bytes that contain a 16~feit unsigned integer. A Packet Type of .141 

identifies the packet as a Personal Display Capability Packet. 

[00466] cClient ID - 2 bytes that contain a 16-bit unsigned integer reserved for the Client 

ID. This field is reserved for future use and shall be set to zero. 

[00467] The Sub-Pixel Layout field contains an 8-bit unsigned integer that specifies the 

physical layout of a sub-pixel from top to bottom and left to right, using value of: 0 to 
indicate that a sub pixel layout is not defined; 1 to indicate red, green, blue stripe; 2 to 
indicate blue, green, red stripe; 3 to indicate a quad-pixel, having a 2-by-2 sub-pixel 
arrangement of red at the top left, blue at the bottom right, and two green sub-pixels, one at 
the bottom left and the other at the top right; 4 to indicate a quad-pixel, with a 2-by-2 sub- 
pixel arrangement of red at the bottom left, blue at the top right, and two green sub-pixels, 
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one at the top left .and the other at the bottom right: 5 to indicate a Delta (Triad); 6 to 
indicate a mosaic with red, green, and blue overfayed (e.g. LCDS display with field- 
sequential color); and with values 7 through 255 being generally reserved for future use. 

[00468] The Pixel Shape field contains an 8-Mt unsigned integer that specifies the shape of 

each pixel that is composed of a specific configuration sub-pixels, using a value of: 0 to 
indicate that a sub-pixel shape is not defined; 1 to indicate round; 2 to indicate square; 3 to 
indicate rectangular; 4 to indicate oval; 5 to indicate elliptical; and with the values 6 
through 255 being reserved for future use in indicating desired chapes, as can be 
■ appreciated by one skilled in the art. 

[00469] Horizontal Field of View (HFOV) field - 1 byte that contains an 8-bit unsigned 

integer that specifies the horizontal field of view in 0.5 degree increments (e.g. if the HFOV 
is 30 degrees, this value is 60). If this value is zero then the HFOV is not specified. 

[00470] Vertical Field of View (V FQ V) field - 1 byte that contains an 8-bit unsigned integer 
that specifies the vertical field of view in 0.5 degree increments (e.g. if the VFOV is 30 
degrees, this value is 60). If this value is zero then the VFOV is not specified, 

[00471] Visual Axis Crossing field - 1 byte that contains an 8-bit unsigned integer that 
specifies the visual axis crossing in 0.01 diopter (1/m) increments (e.g. if the visual axis 
crossing is 2.22 meters, this value is 45). If this value is zero then the Visual Axis Crossing 
is not specified. {Note; is the specification of this parameter appropriate for the desired 
range in most applications? } 

[00472] Left/Right Image Overlap field - 1 byte that contains an 8-bit unsigned integer that 
specifies the percentage of overlap of the left and right image. The allowable range of the 
image overlap in percent is 1 to 100. Values of 101 to 255 are invalid and shall not be used. 
If this value is zero then the image overlap is not specified. 

[00473] Sec Through field - 1 byte that contains an 8-bit unsigned integer that specifies the 

see-through percentage of image. The allowable range of see-through in percent is 0 to 
100. Values of 101 to 254 are invalid and shall not be used. If this value is 255 then the 
see-through percentage is not specified 

[00474] Maximum Brightness field - 1 byte that contains an 8-bit unsigned integer that 

specifies the maximum brightness in increments of 20 nits (e.g. if the maximum brightness 
is 100 nits, this value is 5). If this value is zero then the maximum brightness is not 
specified. 
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[00475] Optica! Capability Hags field - 2 bytes that contain a 16-bit unsigned integer that 

contains various fields that specify optical capabilities of the display. 
[00476] 1 Bits 15 through 5 - reserved for future use, shall be set to zero. 
[00477] Bit 4 - Eye Glass Focus Adjustment 

[00478] 0 - the display has no eye glass focus adjustment. 

[00479] 1 - the display has an eye glass focus adjustment. 

[00480] Bits 3 through; 2 - Binocular Function 

[0048 i] 0 - the display is binocular and can display 2 dimensional (2D) images only. 

[00482] 1 - the display is binocular and can display 3-dimensionai (3D) images. 

[00483] 2 - the display is monocular. 

[00484] 3 - reserved for future use. 

[00-185] Bits 1 through 0 - Left-Right Field Curvature Symmetry 

[00486] 0 - Field curvature not defined. If this field is zero then all field, curvature values 

from Al through ES shall be set to zero except for point C3, which shall specify the focal 
distance of the display or be set. to zero to indicate the focal distance is not specified, 

[00487] 1 - Left and Right displays have the same symmetry. 

[00488] 2 - Left and right displays are mirrored on the vertical axis (column C). 

[00489] 3 - reserved for future use. 

[00490.1 Inter-Pupillary Distance (IPD) Minimum - i byte that contains an 8-bit unsigned 

integer that specifies the minimum inter-pupillary distance in millimeters (mm). If this 
value is zero then the minimum inter-pupillary distance is not specified. 

[00491] Inter-Pupillary Distance (IPD) Maximum - 1 byte that contains an S-bit unsigned 
integer that specifies the maximum inter-pupillary distance in millimeters (mm), If this 
value is zero then the maximum inter-pupillary distance is not specified. 

[00492] Points of Field Curvature List - a list of 25 2-byte parameters that specify the focal 

distance in thousandths of a diopter (1/m) with a range of 1 to 65535 (e.g. 1 is 0,001 
diopters and 65535 is 65.535 diopters). The 25 elements in the Points of Field Curvature 
List are labeled Al through E5 as shown- in Error! Reference source not found, below. 
The. points shall be evenly distributed over the active area of the display. Column C 
corresponds to the vertical axis, of the display and row 3 corresponds to the horizontal axis 
of the display. Columns A and E correspond to the left and right edges of the display, 
respectively, And rows 1 and 5 correspond to the top and bottom edges of the .display, 
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respectively. The order of the 25 points in the list is: Al, Bl, CI, DI, EI, A2, B2, C2, D2, 
E2, A3, B3, C3, D3, E3, A4,.B4, C4, D4, E4, A5, B5, C5, D5, E5, 
[00493] CRC - 2 bytes that contain- a 16-bit CRC of all bytes in the packet including the 

Packet Length, 
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Display Error Report Packet 

[004941 The Display Error Report Packet acts as a mechanism or means for allowing a client 
to provide a list of operating errors to the host. The client may detect a wide range of errors 
in the course of its normal operation as a result of receiving certain commands from the 
host. Examples of these errors include: the client may have been commanded to operate in 
a mode that it does not support, the client may have received a packet containing certain 
parameters that are out of range or are beyond the capability of the client, the client may 
have been commanded to enter a mode in an improper sequence. The Display Error Report 
Packet may be used to detect errors during normal operation, but is most useful to the 
system designer- and integrator to diagnose problems in development and integration of host 
and client systems. The client shall indicate its ability to send the Display Error Report 
Packet via a parameter value of 142 in the Valid Parameter Reply List of the Valid Status 
Reply List Packet 



Display Error Report Packet 



I Packet [p 
) Length | 



Frror Code List 



Pactetf Length - 8 bytes 
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Packet Contents: 

[00495] Packet Length - 2 bytes that contain a 16-bit unsigned integer that specifies the total 

number of bytes in the packet not including the packet length field. 
[00496] Packet Type - 2 bytes that contain a 16-bit unsigned integer. A Packet Type of 142 

identifies the packet as a Display Error Report Packet. 
[00497] cCIient ID -2 bytes that: contain is reserved for the Client ID. This field is reserved 

for future use and shall be sat to zero. 
[00498} Number of list Items - 2 bytes that contain a 16-bit unsigned integer that specifies 

the number of items in the following Error Code List, 
[00499] Error Code List - a. list containing one or more Error Report List items. The format 

of a single Error Report List item is shown in Error! Reference source not found.. 

Error Report List Item 



[00500] In one embodiment, each Error Report List Item is exactly 4 bytes in length, and has 
a structure in one embodiment comprising: a 2-byte Display Error Code field that specifies 
the type of error being reported, a 2-byte Error Sub-code field specifies a greater level of 
detail regarding the error defined by the Display Error Code packet. The specific definition 
of each Display Error Code is defined by the manufacturer of the client. An Error Sub-code 
does not have to be defined for every Display Error Code, and in those eases where the 
Error Sub-code is not defined the value is set to zero. The specific definition of each Error 
Sub-code is defined by the .manufacturer of the client. 



Display Identification Packet 

[00501] The Display Identification Packet allows a client to return identifying data in 

response to a Request Specific Status Packet. In one embodiment, a client indicates an 
ability to send the Display Identification Packet using a parameter value of 144 in the Valid 
Parameter Reply List of the Valid Status Reply list Packet. It is useful for the host to be 
able to determine the client device manufacturer name and model number by reading this 
data from the client. The information may be used to determine if the client has special 
capabilities that cannot described in the Display Capability Packet. There are potentially 
two methods, means, of mechanisms for reading identification information from the client. 
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One is through use of the Display Capability Packet, which contains fields similar to those 
in the base EDID structure. The other metiiod is through use of the Display Identification 
Packet that contains a richer set of information compared to the similar fields in the Display 
Capability Packet. This allows a host to identify manufacturers that have not been assigned 
a 3-character EISA code, and allows serial numbers to contain alphanumeric characters. 
Display Identification Packet 



2byt*s 2 bytes 2 bytes 1 byte 1 byte 2 bytes 2 bytes 2by;es 

j^Manuteurer Name String j Frofoct Warns String j Serial Numfaaf String j CRC J 
Length of Mfr Name bytes Length of Mtr Name bytes Length of Mfr Nsme bytes 2 bytes 

[00502] The 2- byte Packet Type field contains a value that identifies the packet as a Display 

Identification Packet. This value is selected to be 144 in one embodiment. The cClient ID 
field (2 bytes) again is reserved for future use for the Client ID, and is generally set to zero. 
The CRC field (2 bytes) contains a 16-bit CRC of all bytes in the packet including the 
Packet Length. 

[00503] A 1-byte Week of Manufacture field contains a value that defines the week of 

manufacture of the display. In at least one embodiment, this value is in the range of 1 to 53 
if it is supported by the client. If this field is not supported by the client, then it is generally 
set to zero. A 1-byte Year of Manufacture field contains a value that defines the year of 
manufacture of the display. This value is an offset from the year 1990 as a starting point, 
although other base years could be used. Years in the range of 1991 to 2245 can be 
expressed by this field. Example: the year 2003 corresponds to a Year of Manufacture 
value of 13. If this field is not supported by the client it is to be set to a value of aero, 

[00504] The- Length of Mfr Name, Length of Product Name, and Length of Serial Number 
fields each contain 2-byte values that specify the length of the Manufacturer Name String 
field including any null termination or null pad characters, the length of the Product Name 
String field including any null termination or null pad characters, and the length of the 
Serial Number String field including any null termination or noil pad characters, 
respectively. 

[00505] The Manufacturer Name String, Product Name String, and Serial Number String 
fields each contain a variable number of bytes -specified by the Length Mfr Name, Product 
Name, and Serial Number fields, respectively, that contain an ASCII string that specifies 
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the manufacturer, product name , and alphanumeric serial number of the display, 
respectively. Each of these strinp are terminated by at least one null character. 

.. iA: kt 1 

[005Q6] The Alternate Display Capability Packet indicates the capability of the alternate 

displays attached to the MDDI client controller. It is sent in response to a Request Specific 
Status Packet. When prompted a client device sends an Alternate Display Capability Packet 
for each alternate display that is supported. The client shall indicate its ability to send the 
Alternate Display Capability Packet via a parameter value of J 45 in the Valid Parameter 
Reply List of the Valid Status Reply List Packet. 

[00507J For MDDI systems operated in internal mode it may be common to have more than 

one display connected to an MDDI client controller. An example application is a mobile 
phone with a large display on the inside of the flip and a smaller display on the outside. 
The Number of Alt Displays field of the Display Capability Packet is used to report that 
more than one display is attached and the Alternate Display Capability Packet reports the 
capability of each alternate display. The video stream packet contains 4 bits in the Pixel 
Data Attributes field to address each alternate display in the client device. 
Alternate Display Capability Packet 



| *MW\ [ P Height | 



Packet Contents: 

[00508] Packet Type - 2 bytes that contain a 16-bit unsigned integer. A Packet Type of 145 

identifies the packet as an Alternate Display Capability Packet. 

[00509] cClient ID - 2 bytes- that contain a 16-bit unsigned integer reserved for the Client 

ID, This field is reserved for future use and shall be set to zero. 

[00510] Alt Display Number - 1 byte that contains an 8-bit unsigned integer that indicates 

the identity of the alternate display with an integer in the range of 0 to 15. The first 
alternate display shall be number 0 and the other alternate displays shall be identified with 
unique Alt Display Number values with the largest value used being the total number of 
alternate displays minus 1, Values larger than the total number of alternate displays minus 
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1 shall not be used. Example: a mobile: phone having a primary display and a caller-ID 
display connected to an MDDI client has one alternate display, so the Alt Display Number 
of the caller-ID display is zero and the Number of Alt Displays field of the Display 
Capability Packet has a value of 1. 
[00511] Reserved 1-1 byte that contains an 8-bit unsigned integer that is reserved for future 

use. All bits in this field shall be set to zero. The purpose of this field is to cause all 
subsequent 2 byte fields to align to a 16-bit word address and cause 4-byte fields to align to 
a 32-bit word address. 

[00512] Bitmap Width - 2 bytes that contain a 16-bit unsigned integer that specifies the 

width of the bitmap expressed as a number of pixels. 

[00513] Bitmap Height - 2 bytes that contain a 16-bit unsigned integer that specifies the 

height of the bitmap expressed as a number of pixels. 

[00514] Display Window Width - 2 bytes that contain a 16-bit unsigned integer mat 
specifies the width of the display window expressed as a number of pixels. 

[00515] Display Window Height - 2 bytes that contain a 16-bit unsigned integer that 

specifies the height of the display window expressed as a number of pixels. 

[00516] Color Map RGB Width - 2 bytes that contain a 16-bit unsigned integer that specifies 

the number of bits of the red, green, and blue color components that can be displayed in the 
color map (palette) display mode. A maximum of 8 bits for each color component (red. 
green, and blue) can be used. Even though 8 bits of each color component are sent in the 
Color Map Packet, only the number of least significant bits of each color component 
defined in this field are used. If the display client cannot use the color map (palette) format 
then this value is zero. The color map RGB Width word is composed of three separate 
unsigned values: 

[005 17] Bits 3 through 0 define the maximum number of bits of blue in each pixel. 0 to S is 

valid. 

[0D51S] Bits 7 through 4 define the maximum number of bits of green in each pixel. 0 to S is 

valid. 

[005 19] Bits 1 1 through 8 define the maximum number of bits of red in each pixel. 0 to 8 is 

valid. 

[00520] Bits 15 through 12 are reserved for future use and shall be set to zero. 

[00521] RGB Capability - 2 bytes that contain a 16-bit unsigned integer that specifies the 

number of bits of resolution that can be displayed in RGB format. If the client cannot use 
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the RGB format then this value is zero. The RGB Capability word is composed of three 
separate unsigned values: 
[00522] Bits 3 through 0 define the maximum number of bits of blue (the blue, intensity) in 

each pixel. 

[00523] Bits 7 through 4 define the maximum number of bits of green (the green intensity) 

in each pixel. 

[00524] Bits 11 through 8 define the maximum number of bits of red (the red intensity) in 

each pixel. 

[00525] Bits 15 through 12 are reserved for future use and shall be set to zero. 

[00526] Monochrome Capability - 1 byte that contains an 8-bit unsigned integer that 

specifies the number of bits of resolution that can be displayed in monochrome format. If 
She client cannot use the monochrome format then this value is zero. Bits 7 through 4 are 
reserved for future use and shall be set to zero. Bits 3 through 0 define the maximum 
number of bits of grayscale that can exist in each pixel. These four bits make it possible to 
specify that each pixel consists of 1 to 15 bits. If the value is zero then the monochrome 
format is not supported by the client. 

[00527] Reserved 2-1 byte that contains an 8-bit unsigned integer that is reserved for future 
use. All bits in this field shall be set to zero. The purpose of this field is to cause all 
subsequent: 2 byte fields to align to a 16-bit word address and cause 4-byle fields to align to 
a 32-bit word address. 

[00528] Y Cb Cr Capability - 2 bytes that contain a 16-bit unsigned integer that specifies the 

number of bits of resolution that can be displayed in Y Cb Cr format. If the client cannot 
use the Y Cb Cr format then this value is zero. The Y Cb Cr Capability word is composed 
of three separate unsigned values: 

[00529] Bits 3 through 0 define the maximum number of bits that specify the Cb sample. 

[00530] Bits 7 through 4 define the maximum number of bits that specify the Cr sample. 

[0053 1] Bits 1 1 through 8 define the maximum number of bits specify the Y sample. 

[00532] Bits 15 through 12 are reserved for future use -and shall be set to zero. 

[00533] Display Feature Capability Indicators - 1 byte that contains an 8-bit unsigned 

integer that contains a set of flags that indicate the whether specific features in the client are 
supported. A bit set to one indicates the capability is supported, and a bit set to zero 
indicates the capability is not supported. 

[00534] Bit 0 - the client can accept video data in packed, format 
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[00535] Bits 1 through 7 - reserved for future use, shall be set to zero. 

[00536] Reserved 3 - I byte that contains an 8-bit unsigned integer that is reserved for future 

use, AU bits in this field shall be set to zero. The purpose of this field is to cause all 
subsequent 2 byte fields to align to a 16-bit word address and cause 4-byte fields to align to 
a 32-bit word address, 

[00537] CRC - 2 bytes that contain a 16-bit CRC of all bytes in the packet including the 

Packet Length. 

Register Access Packet 

1 0Q5 3 SI The Register Access Packet provides either a host ox a client with a. means, 

mechanism, or method to access configuration and status registers in the opposite end of the 
MDDI link, These registers are likely to be unique for each display or device controller. 
These registers already exist in many displays that require setting configurations, modes of 
operation, and have other useful and necessary settings. The Register Access Packet allows 
the MDDI host or client to both write to a register and request to read a regi ster using the 
MDDI link. When the host or client requests to read a register the opposite end should 
respond by sending the register data in the same packet type, but also by indicating that this 
is the data read from a particular register with the use of the Read/Write Info field. The 
Register Access Packet may be used to read or write multiple registers by specifying a 
register count greater than 1. A client indicates an ability to support the Register Access 
Packet using bit 22 of Display Feature Capability Indicators field of the Display Capability 
Packet 

Register Access Pauket 

1 g£ U^el 1 ^aterPataUst [ CRC | 

2 bytes 2 bytes 2 bytes Zbyies 4 bytes Packet Length - 12 bytes 2 bytes 

.Register Access Packet 

[00539] The 2-byte Packet Length field contain a 16-bit unsigned integer that specifies the 
total number of bytes in the packet not including the packet length, field. 

[00540] Packet Type - 2 bytes that: contain a 16-bit unsigned integer. A Packet Type of 146 

identifies the packet as a Register Access Packet. 

[00541] bClient ID - 2 bytes that contain a 16-bit unsigned integer reserved for the Client 

ID. This field is reserved for future use and shall be set to zero. 
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[00542] Read/Write Info - 2 bytes that contain a 16-bit unsigned integer that specifies the 
specific packet as either a write, or a read, or a response to a read, and provides a count of 
the data values 

[00543] BitBits 15 through 14 - Read/Write Flags 

[00544] BitBits[15:14] - 10 - Host this is a request for data from a one or more registers 

addressed by the Register Address field 
[00545] BiiBits[1.5:14] - 00 - writethis packet contains data to be written to a register 

addressed by the Register Address field. The data to be written to the specified registers is 

contained in the Register Data field 
[00546] BitBits[15:14] = 11 - that eontainhis packet contains data that was requested in 

response to a Register Access Packet having Read/Write Flags set to 10, The Register 

Address field shall contain the address of the register corresponding to the first Register 

Data item, and the Register Data field shall contain the data that was read from the address 

or addresses. 

[00547] Bit Bits[15; 14] = 10 - this : value is reserved for future use and shall not be used, 

[00548] Bits 13:0 - a 14-bit unsigned integer that specifies the number of 32-bit Register 

Dataitems o be transferred in the Register Data List field. 
[00549] If bit 15 is 0 in a packet sent by the host then bits 13:0 specify the number of register 

data items mat are contained in the Register Data List field to be written to client registers 

starting at the register specified by the Register Address field. 
[00550] If bit 15 is a 1 in a packet sent by the host bits 13:0 specify the. number of register 

data items that the client shall send to the host. The Register Data field in the packet sent 

by the host shall contain no items and is of zero length. 
[00551] If bit 15 is a 1 in a packet sent by the client then bits 13:0 specify the number of 

register data items that are contained in the Register Data List field. 
[00552] Bit 15 shall not be set to 0 in packets sent by the Client. This is not a valid value. 

[00553] Register Address - 4 bytes that contain a 32-bit unsigned integer that contains the 

register address that is to be written to or read from. For addressing registers whose 

addressing is less than 32 bite, the upper bits- shall be- set to zero. 
[00554] Register Data List - a list of 4-byte register data values to be written to client- 

registers or values that were read from client device registers. 
[00555] CRC - 2. bytes that contain a 16-bit CRC -of all bytes in the packet including the 

Packet Length. 
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Frame Sync Packet 

[00556] The Frame Sync Packet provides a 'host an ability to indicate the start of a raster 

i mage and allows a client to avoid using the -pixel and window addressability features in the 
Video Stream Packet. This is aceotnlished by sending a Frame Sync Packet at the start of 
each frame of the image, and then one Video Stream Packet (with bit 5 set in the Pixel Data 
Attributes field) is sent for each row of image data. In one embodiment, a client indicates 
an ability to support the Frame Sync Packet using bit 23 of the Display Feature Capability 
Indicators field of the Display Capability Packet. 
The format 



Frame Sync Packet 


Packet 
Length 


Packet 
Type = 147 


bCllent fD 


CRC 


2 bytes 


2 bytes 


2 bytes 


2 bytes 



[00557] Packet Type - 2 bytes that contain a 16-bit unsigned integer. A Packet Type of 

147 identities the packet as a Frame Sync Packet. 
[00558] bClient ID - 2 bytes that contain a 16-bit unsigned integer reserved for the Client 

ID. 

D. Packet CRC 

[00559] The CRC fields appear at the end of the packets and sometimes after certain more 

critical parameters in a packet that may have a significantly large data field, and thus, an 
increased likelihood of errors during transfer. In packets that have two CRC fields, the 
CRC generator, when only one is used, is re-initialized after the first CRC so that the CRC 
computations following a long data field are not affected by the parameters at the beginning 
of the packet. 

[00560] In an exemplar)' embodiment, the polynomial used for the CRC calculation is 
known as the CRC 16, or X16 + X15 + X2 + X0. A sample implementation of a CRC 
generator and checker 3600 useful for implementing the invention is shown in FIG. 36. In 
FIG. 36, a CRC register 3602 is initialized to a value of 0x0001 just prior to transfer of the 
first bit of a packet which is input- on the Tx_MDDI_Data_ Before CRC n n&t then the bytes 
of the packet are shifted into the register starting with the LSB first. Note that the register 
bit numbers in this figure correspond to the order of the polynomial being used, and not the 
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bit positions used by the MDDI. It is more efficient to shift the- CRC register in a single 
direction, and this results in having CRC bit 15 appear in bit position 0 of the MDDI CRC 
field, and CRC register bit 14 in MDDI CRC field bit position 1, and so forth until MDDI 
bit position 14 is reached. 

[00561] As an example, if the packet contents for the Display Request and Status Packets 

are: 0x07, 0x46, 0x000400, 0x00 (or represented as a sequence of bytes as: 0x07, 0x00, 
0x46, 0x00, 0x04, 0x00, 0x00), and are submitted using the inputs of the multiplexors 3604 
and 3606, and NAND gate 3608, the resulting CRC output on the 
Tx MDDl_Data_With.CRC line is OxOeal (or represented as a sequence as Oxal, OxOe), 

[00562] When CRC generator and checker 3600 is configured as a CRC checker, the CRC 

that is received on the Rx„MDDI_Data line is input to multiplexor 3604 and NAND gate 
3608, and is compared bit by bit with the value found in the CRC register using NOR gate 
3610, exclusive-OR (XOR) gate 3612, and AND gate 3614. If there are any errors, as 
output by AND gate 3614, the CRC is incremented once for every packet that contains a 
CRC error by connecting the output of gate 3614 to the input of register 3602, Note that, the 
example circuit shown in the diagram of FIG. 36 can output more than one CRC error 
signal within a given CHECK_CRC_NOW window (see FIG. 37B). Therefore, the CRC 
error counter generally only counts the first CRC error instance within each interval where 
CHECK_CRC .NOW is active. If configured as a CRC generator the CRC is clocked out 
of the CRC register at the time coinciding with the end of the packet. 

[00563] The timing for the input and output signals, and the enabling signals, is illustrated 

graphically in FIGS. 37A and 37B. The generation of a CRC and transmission of a packet 
of data are shown in FIG, 37A with the state (0 or 1) of the GenJReset, Check_CRC_Now, 
Generate„CRC_Now, and Sending_MDDIJOata signals, along with the 
Tx_MDDLDataJBefoie_CRC and Tx JN4DDI_Data_Wi th_CRC signals. The reception of 
a packet of data and checking of the CRC value are shown in FIG. 37B, with the state of the 
Genjteset, Check„CRCJNow, Generate JjRCJS t ow, .and Sending_MDDI_Data signals, 
along with the Rx MDDIJData and CRC error signals. 

Error Code -Overload for Packet CEC 

[00564] Whenever only data, packets and CRC are being transferred between the: host and 

client, there are no error codes being accommodated. The only error is a loss of 
synchronization. Otherwise, one has to- wait for the link to timeout from a lack of a good 
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data transfer path or pipeline and then reset the link and proceed. Unfortunately, this is time 
consuming and somewhat inefficient. 

[00565] For use in one embodiment, a new technique has been developed in which the CRC 

portion of packets is used to transfer error code- information. This is generally shown in 
FIG, 65. That is, one or more error codes are generated by the processors or devices 
handling the data transfer which indicate specific predefined errors or flaws that might 
occur within the communication processing or link. When an error is encountered, that the 
appropriate error code is generated and transferred using the bits for the CRC of a packet. 
That is, the CRC value is overloaded, or overwritten, with the desired error code, which can 
be detected on the receiving end by an error monitor or checker that monitors the values of 
the CRC field. For those cases in which the error code matches the CRC value for some 
reason, the compliment of the error is transferred to prevent confusion. 

[00566] In one embodiment, to provide a robust error warning and detection system, the 

error code may be transferred several times, using a series of packets, generally all, that are 
transferred or sent after the error has been detected. This occurs until the point at which the 
condition creating the error is cleared from the system, at which point the regular CRC bits 
are transferred without overloading by another value. 

[00567] This technique of overloading the CRC value provides a much quicker response to 

system errors while using a minimal amount of extra bits or fields. 

[00568] As shown in FIG. 66, a CRC overwriting mechanism or apparatus 6600 is shown 
using an error detector or detections means 6602, which can form part of other circuitry 
previously described or known, detects the presence or existence of errors within the 
communication link or process. An error code generator or means 6604, which can be 
formed as part of other circuitry or use techniques such as look up tables to store pre- 
selected error messages, generates one or more error codes to indicate specific predefined 
errors or flaws that have been detected as occurring. It is readily understood that devices 
6602 and 6604 can be formed as a single circuit or device as desired, or as part of a 
programmed sequence of steps for other known processors and elements. 

[00569] A CRC value comparator or comparison means 6606 is shown for checking to see if 
the selected error code or codes are the same as the CRC value being transferred. If tliat is 
the case then a code compliment generator or generation means or device is used to provide 
the compliment of the error codes as to not be mistaken as the. original CRC pattern, or value 
and confuse or complicate the detection scheme. An error code selector or selection means 
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element or device 6610 then selects the .error code or value it is desired to insert or 
overwrite, or their respective compliments as appropriate. An error code CRC over-writer 
or over writing mechanism or means 6612 is a device that receives the- data stream, packets, 
and the desired codes to be inserted and overwrites the corresponding or appropriate CRC 
values, in order to transfer the- desired error codes to a receiving device. 
[00570] As mentioned, the error code may be transferred several times, using a series of 

packets, so the over-writer 6612 may utilize memory storage elements in order to maintain 
copies of the codes during processing or recall these codes from previous elements or other 
known storage locations which can be used to store or hold their values as needed, or as 
desired. 

[00571] The general processing the overwriting mechanism of FIG. 66 is implementing is 
shown in additional detail in HGS. 67A and 67B. In 67 A an error, one or more, is detected 
in step 6702 in the communication data or process and an error code is selected in step 6704 
to indicate this condition. At the same time, or at an appropriate point, the CRC value to he 
replaced is cheeked in a step 6706, and compared to the desired error code in step 6708. 
The result of this comparison, as discussed earlier, is a determination as to whether or not: 
the desired code, or other representative values, will be the same as the CRC value present 
If this is the case, then processing proceeds to a step 6712 where the compliment, or in 
some cases another representative value, as desired, is selected as the code to insert. One it 
has been determined what error codes or values are to be inserted in steps 6710 and 6714, 
that appropriate code is selected for insertion. These steps are illustrated as separate for 
purposes of clarity but generally represent a single choke based on the output of the step 
6708 decision. Finally, in step 6716 the appropriate values are overwritten in the CRC 
location for transfer with the packets being targeted by the process. 

[00572] On the packet reception side, as shown in FIG. 67B, the packet CRC values are 

being monitored in a step 6722. Generally, the CRC values are being monitored by one or 
more processes within the system to determine if an error in data transfer has occurred and 
whether or not to request a retransmission of the packet or packets, or to inhibit further 
operations and so forth, some of which is; discussed above. As part of such monitoring the 
information can also be used to compare values to known or preselected error codes, or 
representative values and detect the presence of errors. Alternatively, a separate error 
detection process and monitor can be implemented. If a code appears to be present it is 
extracted or otherwise, noted in step 6724 for further processing. A determination can be 
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made in step 6726 as to whether or not this is the actual code or a compliment, in which 
case an additional step 6728 is used to translate the value to the desired code value. In 
either case the resulting extracted code, compliment, or other recovered values are then 
used to detect what error has occurred form the transmitted code in step 6730. 

V. Link. Restart from Hibernation 

[QG573] When the host restarts- the forward Jink from a hibernation state it drives 
MDDI J>ata to a logic one state for about 150 jisec and then activates M.DDI_Stb and 
simultaneously drives MDDIJData to a logic zero state for 50 jxsec, and then starts forward 
link traffic by sending a sub-frame header packet. This generally allows bus contentions to 
be resolved before the sub-frame header packet is sent by providing enough settling time 
between signals. 

[00574] When the client, here a display, needs data or communication from the host it drives 
the MDDI_Data0 line to a logic one state for around 70 usee, although other periods can be 
used as desired, and then disables the driver by placing it in a high-impedance state- This 
action causes, the host to start or restart data traffic on the forward link (208) and. to poll the 
client for its status. The host must detect the presence of the request pulse within 50 p:sec 
and men begin the startup sequence of driving MDDIJDataO to logic one for 150 u.sec and 
to logic zero for 50 usee. The display should not send a service request pulse if it detects 
MDDIJDataO in the logic one state for more than 50 jtsec. The nature of selection of the 
times and tolerances of time intervals related to the hibernation processing and start up 
sequence are discussed further below. 

[00575] An example of the processing steps for a typical service request event 3800 with no 
contention is illustrated in FIG. 38, where the events are labeled for convenience in 
illustration using the letters A, B, C, D, E, F, and Q. The process commences at point A 
when the host sends a Link Shutdown Packet to the client device to inform it that the link 
will transition to a low-power hibernation state. In a next step, the host enters the low- 
power hibernation state by disabling the MDBI_Data0 driver and setting the MDDIjStb 
driver to a logic zero, as shown at point B. MDDIJDataO is driven to a logic-zero level by a 
high-impedance bias network. After some period of time, the client sends a service request 
pulse to the host by driving MDDIJDataO to a logic one level as seen at point C. The host 
still asserts the logic-zero level using the high-impedance bias network, but the driver in the 
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client forces the line to a logic one level. Within SO psec, the host recognizes the service 
request pulse, and asserts a logic one level on MDDIJDataO by enabling its driver, as seen 
at point D. The client then ceases from attempting to assert, the service request pulse, and 
the client places its driver into a high-impedance state, as seen at point E. The host drives 
MDDIJDataO to a logic-zero level for 50 usee, as shown at point F, and also begins to 
generate MDDI_Stb in a manner consistent with the logic-zero level on MDDIJDataO. 
After asserting MDDIJDataO to a logic-zero level and driving MDDI_Stb for 50 usee, the 
host begins to transmit data on the forward link by sending a Sub-frame Header Packet, as 
shown at point G. 

[00576] A similar example is illustrated in FIG. 39 where a service request is asserted after 

the link restart sequence has begun, aid the events are again labeled using the letters A, B, 
C, D, E, F, and G. This represents a worst case scenario where a request pulse or signal 
from: the client comes closest to corrupting the Sub-frame Header Packet. The process 
commences at point A when the host again sends a Link Shutdown Packet to the client 
device to inform it that the link will transition to a low-power hibernation state, m a next 
step, the host enters the low-power hibernation state by disabling the MDDIJDataO driver 
and setting the MDDI_Stb driver to a logic zero* as shown at point: B. As before, 
MDDIJDataO is driven to a logic-zero level by a high-impedance bias network. After a 
period of time, the host begins the link restart sequence by driving MDDI_DataO to a logic 
one level for 150 psec as seen at point C. Prior to 50 jjlscc passing after the link restart 
sequence begins the display also asserts MDDIJDataO for a duration of 70 usee, as seers at 
point D. This happens because the display has a need to request service from the host and 
does not recognize that the host has already begun the link restart sequence. The client then 
ceases attempting to assert the service request pulse, and the client places its driver into a 
■high-impedance state, as seen at point E. The host continues to drive MDDIJDataO to a 
logic one level. The host drives MDDIJDataO to a logic zero level for 50 pec, as shown at 
point F, and also begins to generate MDDl JStb in a manner consistent with the logic zero 
level on MDDIJDataO. After asserting MDDIJDataO to a logic-zero level, and driving 
MDDI_Stb for 50 psec, the host begins to transmit data on the forward link by sending a 
Sub-frame Header Packet, as shown at point G. 

[00577] From the above discussion, one sees that the prior solution involved having the host 

go through two states as part of a wakeup sequence. For the first state, the host drives the 
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MDDIJDataO signal high for 150 us,, and then drives the MDDI ...DaUiO signal low for 50us 
while activating the MDDIJStb line,, and then begins to transmit MDDI packets. This 
process works well to advance the state of the art in terms of data rates achievable using the 
MDDI apparatus and methods. However^ as stated earlier, more speed in terms of reduced 
response time to conditions or being able to more quickly select the next step or process, are 
the ability to simplify processing or elements, are always in demand. 

[00578] Applicants have discovered a new inventive approach to wake-up processing and 

timing in which the host uses a clock cycle based timing for the signal toggling. In this 
configuration, the host starts toggling MDDI_Stb from 0 to 10 usee after the host drives the 
MDDIJDataO signal high at the beginning of the wake-up sequence, and docs not wait until 
the signal is driven low. During a wake-up sequence, the host toggles MDDl_Stb as though 
the MDDIJDataO signal were always at a logic-zero level. This eftc.-, ;1> remover, ths 
concept of time from the client side, and the host changes from the prior 150 us and 50 us 
periods for the first two states, to 150 clock cycles and 50 clock cycles, for these periods. 

[00579] The host now becomes responsible for driving that data line high, and. within 10 
clock cycles starting to transmi t a strobe signal as if the data line was zero, After the host 
has driven the data line high for 150 clock cycles, the host drives the data line low for 50 
clock cycles while continuing to transmit the strobe signal. After it has completed both of 
these processes, the host can begin to transmit the first sub-frame header packel. 

[00580] On the client side, the client implementation can now use the generated clock to 

calculate the number of clock cycles that the data line is first high, and then low. The 
number of clock cycles that need to occur in both the data line driven high state is 150 and 
data line driven low state is 50. This means that for a proper wakeup sequence, the client 
should be abb to count at least 150 continuous clock cycles of the data line being high, 
followed by at least 50 continuous clock cycles of the data line being low. Once these two 
conditions are met, the client can begin- to search for the unique word of the first sub-frame. 
A break in this pattern is used as a basis to return the counters to an initial state in- which the 
client again looks for the first 150 continuous clock cycles of the data line being high. 

[00581] A client implementation of the invention for host based wakeup from hibernation is 

very similar to the initial start-up case except that the clock rate is not forced to start at 
1Mbps., as discussed earlier. Instead the clock rate can be set to resume at whatever 
previous rate was active when the communication link went into hibernation. If the host 
begins transmission of a strobe signal as described above, the client should be able to again 
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count at least 150 continuous clock cycles of the data line being high, followed by at least 
50 continuous clock cycles of the data line being low. Once these two conditions have been 
met, the client can begin the search for the unique word. 

[00582] A client implementation of the invention for client based wakeup from hibernation 

is similar to the host based wakeup except that it starts by having the client driving the data 
line. The client can asynchronously drive the data line without a clock to wake up the host 
device. Once the host recognizes that the data line is being driven high by the client, it can 
begin its wakeup sequence. The client can count the number of clock cycles generated by 
the host starting or during its wakeup process. Onee the client counts 70 continuous clock 
cycles of the data being high, it can stop driving the data line high. At: this point, the host 
should already be driving the data line high as well. The client can then count another 80 
continuous clock cycles of the data line being high to reach the 150 clock cycles of the data 
line being high, and can then look for 50 clock cycles of the data line being low. Once 
these three conditions have been met the client can begin to took for the unique word. 

[00583] An advantage of this new implementation of wake-up processing is that it removes 

the need for a time measuring device. Whether this is an oscillator, or capacitor discharge 
circuit, or other such known devices, the client no longer needs such external devices to 
determine the start up conditions. This saves money and circuit area when implementing 
controllers, counters, and so forth on a client device board. While this may not be as 
advantageous to the client, for the host, this technique should also potentially simplify the 
host in terms of very high density logic (VHDL) being used for core circuitry. The power 
consumption of using the data and strobe lines as the wakeup notification and measurement 
source will also be lower since no external circuitry will need to be running for the core 
elements to be waiting for a host based wakeup. 

[00584] The number of cycles or clock periods used are exemplary and other periods can be 

used as will be apparent to one skilled in the art. 

[00585] An advantage of this new implementation of wake-up processing is that it removes 

the need for a time measuring device. Whether this is an oscillator, or capacitor discharge 
circuit, or other such known devices, the client no longer needs such external devices to 
determine the start up conditions. This saves money and circuit area when implementing 
controllers, counters, and so forth on a client device board. While this may not be as 
advantageous to the client, for the host, this technique should also potentially simplify the 
host in tonus of very high density logic (VHDL). being used for core circuitry. The power 



WO 2005/018191 



PC17US2004/026264 



99 

consumption of using the data and strobe lines as the wakcup notification and measurement 
source will also be lower since no external circuitry will need to be running for the core 
elements to be waiting for a host based wakeup. 

[00586] To clarify and illustrate the operation of this new technique, the timing of 

MDDLDataO, MDDLStb, and various operations relative to the clock cycles are shown in 
FIGS. 68 A, 68B, and 68C, 

[00587] An example of the processing steps" for a typical Host-initiated Wake up with no 

contention is iilustt-ated in FIG. 68 A. where the events are again labeled for convenience in 
illustration using the letters A, B, C, D, E, F, and G. The process commences at point A 
when the host sends a Link Shutdown Packet to the client device to inform it that the link 
will transition to a low-power hibernation state. In a next step, point B, the host toggles 
MDDLStb for about 64 cycles (or as desired for system design) to allow processing by the 
client to be completed prior to stopping MDDLStb from toggling, which stops the 
recovered clock in the client device. The host also initially sets MDDLDataO to logic-zero 
level and then disables the MDDLDataO output in the range of 16 to 48 cycles (generally 
including output disable propagation delays) after the CRC. It: may be desirable to place 
high-speed receivers for MDDLDataO and MDDLStb in the client in a low power state 
some time after the 48 cycles after the CRC and prior to the next stage (C). 

[00588] The host enters the low-power hibernation state at point or step C, by disabling the 
MDDLDataO and MDDLStb drivers and placing a host controller in a low power 
hibernation state. One can also set the MDDLStb driver to a logic-zero level (using a high- 
impedance bias network) or to continue toggling during hibernation, as desired. The client 
is also in a low power level hibernation state. 

[00589] After some period of time, the host commences the link restart sequence at point D, 

by enabling the MDDLDataO and MDDLStb driver output. The host drives MDDLDataO 
to a logic-one level and MDDLStb to a logic-zero level for as long as it should take for the 
drivers to folly enable their respective outputs-. The host typically waits around 200 
nanoseconds after these outputs teach desired logic levels before driving pulses on 
MMOLStb. This allows the client time to prepare to receive. 

[O059O] With the host drivers, enabled and MDDLDataO being driven to a logic-one level, : 

the host begins to toggle MDDLStb for a duration of 150 MDDLStb cycles, as seen at 
point E. The host drives MDDLDataO to a logic zero level for SO cycles,, as shown at point 
F, and the client begins to look for ■the Sub-frame Header Packet, after .MDDLDataO is at a 
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logic-zero level for 40. MDDIjStb cycles. The host begins to transmit data on the forward 
link by sending a Sub-frame Header Packet, as shown at point G. 

[G0S91] An example of the processing steps for a typical Client-initiated Wake-up with no 

contention is illustrated in FIG. 68B, where the events are again labeled for convenience in 
illustration using the letters A, B, C, D, E, F, G, H, and I. As before, the process 
commences at point A when the host sends a Link Shutdown Packet to inform the client 
that the link will transition to the low power state. 

[00S92] At point B, the host toggles MDDLStb for about 64 cycles (or a& desired for system 

desion) to allow processing by the client to be completed prior to stopping MDDLStb from 
toggling, which stops the recovered clock in the client device. The host also initially sets 
MDDLDataO to a logic-zero level and then disables the MDDLDataO output in the range 
of 16 to 48 cycles (generally including output disable propagation delays) after the CRC. It 
may be desirable to place high-speed receivers for MDDLDataO and MDDI_Stb in the 
client, in a low power state some time after the 48 cycles after the CRC and prior to the next 
stage (G). 

[00593] The host enters the low-power hibernation state at point or step C, by disabling the 
MDDI_Data0 and MDDLStb drivers: and placing a host controller in a low power 
hibernation state. One can also set the MDDLStb driver to a logic-zero level (using a high- 
impedance bias network) or to continue toggling during hibernation, as desired. The client 
is also in a low power level hibernation state. 

[00594] After some period of time, the client commences the link restart sequence at point 
D, by enabling the MDDLStb receiver, and also enabling an offset in the MDDLStb 
receiver to guarantee the state of the received version of MDDLStb is a logic -zero level in 
the client before the host enables its MDDLStb driver. It may be desirable for the client to 
enable the offset slightly ahead of enabling the receiver to ensure the reception of a valid 
differential signal and inhibit erroneous signals, as desired* The Client enables the 
MDDLDataO driver while driving the MDDLDataO line to a logic one level 

[00595] Within about 1 msec, point E» the host recognizes the service request pulse from the 

client, and the host begins the link restart sequence by enabling the MDDLDataO and 
MDDLStb driver outputs. The host drives MDDLDataO to a logic-one level and 
MDDLStb to a logic-zero level for as long as it should take for the drivers to enable their 
respective outputs. The host typically waits around 200 nanoseconds .after these outputs 
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reach desired logic levels before driving pulses on MDDI_Stb. This allows the client time 
to prepare to receive, 

[00596] With the host drivers enabled and MDDIJDataO being driven to a logic-one level, 

the host begins outputting pulses on MDDL_.Stb for a duration of 150 MDDI_Stb cycles, as 
seen at point t. When the client recognizes the first pulse on MDDIJSlb it disables the 
offset in its MDDIJStb receiver. The chent continues to drive MDDIJDataO to a logic-one 
level for 70 MDDI_Stb cycles, and disables its MDDIJDataO driver at point G. 

[00597] As seen at points G and H, the host drives MDDIJDataO to a logic-zero level for 50 

cycles, and the client begins to look for the Sub-frame Header Packet after MDDIJDataO is 
at a logic-zero level for 40 MDDIJStb cycles. The host begins to transmit data on the 
forward link by sending a Sub-frame Header Packet, as shown at point I. 

[00598] An example of the processing steps for a typical Host-initiated Wake-up with 

contention from the client, that is the client also wants to wake up the link, is illustrated in 
FIG, 68C, The events are again labeled for convenience in illustration using the letters A, 
B, C. D. E, F, G, H, and . I. As before, the process commences at point A when the host 
sends a Link Shutdown Packet to inform the client that the link will transition to the low 
power state, proceeds to point B where MDDI_Stb is toggled, for about 64 cycles (or as 
desired for system design) to allow processing by the client to be completed, and then to 
point C, where the host enters the low-power hibernation state, by disabling the 
MDDIJDataO and MDDIJStb drivers and placing a host controller in a low power 
hibernation state. After some period of time, the host commences the link restart sequence 
at point D. by enabling the MDDIJDataO and MDDIJSlb driver output, and begins to toggle 
MDDIJStb for a duration of 1 50 MDDIJStb cycles, as seen at point E. 

[00599] At up to 70 MDDIJStb cycles after point E, here point F, the client has not yet 

recognized that the host is driving MDDIJDataO to a logic-one level so the client also 
drives MDDIJDataO to a logic-one level. This occurs here because the client has a desire to 
request service but does not recognize that the host it is trying to communicate with has 
already begun the link restart sequence. At point G, the client eeasss to drive 
MDDIJDataO, and places its driver into a high impedance state by disabling its output. The 
host continues to drive MDDIJDataO to a logic-one level for 80 additional cycles. 

[00600] The- host chives MDDIJDataO to a logic zero level for 50 cycles, as shown at point 

H, and the client begins to look for the Sub-frame Header Packet after MDDIJDataO is at a 
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logic-zero level for 40 MDDI_Stb cycles. The host 'begins to transmit data on the forward 
link by sending a Sub-frame Header Packet, as shown at point I. 

VI. Interface Electrical Specifications 

[00601] In the example embodiments, Data in a Non-Return-to Zero (NRZ) format is 

encoded using a data-strobe signal or DATA-STB format, which allows clock information 
to be embedded in the data and strobe signals. The clock can be recovered without complex, 
phase lock loop circuitry. Data is carried over a bi-directional differential link, generally 
implemented using a wire-line cable, although other conductors, printed wires, or transfer 
elements can be used, as stated earlier. The strobe signal (STB) is carried over a uni- 
directional link which is driven only by the host. The strobe signal toggles value (0 or 1) 
whenever there is a back-to-back state, 0 or 1, that remains the same on the Data line or 
signal. 

[00602] An example of how a data sequence such as bits "1110001011" can be transmitted 
using DATA-STB encoding is shown in graphical form in FIG. 40. In FIG, 40, a DATA 
signal 4002 is shown on the top line of a signal timing chart and a STB signal 4004 is 
shown on a second line, each time aligned as appropriate (common starting point), As time 
passes, when there is a change of state occurring on the DATA line 4002 (signal), then the 
STB line 4004 (signal) maintains a previous state, thus, the first T state of the DATA signal 
correlates with the first '0' state for the STB signal, its starting value. However, if or when 
the state, level, of the DATA signal does not change then the STB signal toggles to the 
opposite state or T in the present example, as is the case in FIG. 40 where the DATA is 
providing another 1' value. That is, there is one and only one transition per bit cycle 
between DATA and STB, Therefore, the STB signal transitions again, this time to '0' as the 
DATA signal stays at. T and holds this level or value as the DATA signal changes level to 
'0'. When the DATA signal stays at '1', the STB signal toggles to the opposite state or T in 
the present example, and so forth, as the DATA signal changes or holds levels or values. 

[00603] Upon receiving these signals, an exclnsivc-OR (XOR) operation is performed on the 

DATA and STB signals to produce a clock signal 4006, which is shown on the bottom of 
the timing chart for relative, comparison with the desired data and strobe signals. An 
example of circuitry useful for generating the DATA and STB outputs or signals from input 
data at the host, and then recovering or recapturing the data from the DATA and STB 
signals at the client, is shown in FIG. 41. 
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[00604] In FIG, 41, a transmission portion 4100 is used to generate and transmit the original 

DATA and STB signals over an intermediary signal path 4102, while a reception portion 
4120 is used to- receive the signals and recover the data. As shown in FIG 41, in order to 
transfer data from a host to a client, the DATA signal is input to two D-type flip-flop circuit 
elements 4104 and 4106 along with a clock signal for triggering the circuits. The two flip- 
flop circuit outputs (Q) are then split into a differential pair of signals MDDI_Data0+. 
MDDLDataO- and MDDI_Stb+, MDDIJStb-, respectively, using two differential line 
drivers 4108 and 4110 (voltage mode). A three-input exclusive-NOR (XNOR) »ate, circuit 
or logic element 41 12 is connected to receive the DATA and outputs of both flip-flops, and 
generates an output that provides the data input for the second flip-flop, which in turn 
generates the MDDI Stb-h MDDI_Stb- signals. For convenience, the XNOR gate has the 
inversion bubble placed to indicate that it is effectively inverting the Q output of the flip- 
flop that generates the Strobe. 

[00605] In reception portion 4120 of FIG 41, the MDDI._DataQ+, MDDLDataO- and 
MDDI_Stb+, MDDLStb- signals are received by each of two differential line receivers 
4122 and 4124, which generate single outputs from the differential signals. The outputs of 
the amplifiers are then input to each of the inputs of a two-input exclusive-OR (XOR) gate, 
circuit, or logic element 4126 which produces the clock signal. The clock signal is used to 
trigger each of two D-type flip-flop circuits 4128 and 4130 which receive a delayed version 
of the DATA signal, through delay element 4132, one of which (4128) generates data '0' 
values and the other (4130) data T values. The clock has an independent output from the 
XOR logic as well. Since the clock information is distributed between the DATA and STB 
lines, neither signal transitions between states faster than half of the clock rate. Since the 
clock is reproduced using the exclusive OR processing of the DATA and STB signals, the 
system effectively tolerates twice the amount of skew between the input data and clock 
compared to the situation when a clock signal is sent directly over a single dedicated data 
line. 

[00606] The MDDI Data pairs, MDDI_jStb+, and MDDI_Stb- signals are operated in a 
differential mode to maximize immunity from the negative affects of noise. Each portion of 
the differential signal path is source terminated with one-half of the characteristic 
impedance of the cable or conductor being used to transfer signals. MDDI Data pairs are 
source terminated at both the host and client ends. Since only one of these- two drivers is 
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active, at a given time, a termination continuously exists at the source for the transfer link. 
The MDDI_Stb+ and MDDIStb- signals are only driven by the host. 
[00607] An exemplary configuration of elements useful for achieving the drivers, receivers, 

and terminations for transferring signals as part of the inventive MDD interface are shown 
in FIG. 42, while corresponding DC electrical specifications of MDDLData and 
MDDI_Stb are shown in Table VII. This exemplary interface uses low voltage sensing, 
here 200 mV, with less than 1 volt power swings and low power drain. 



TABLE Vi! 



Parameter 


Description 


Min. 


Typ 


Max. 


Units 




Series Termination 


413 


42.2 


43.0 


Ohms 


Jkltoate , 


Hibernate State bias termination 


8 


10 


12 


K-Ohms 




Hibernate State open-circuit 
voltage 


0.5 




2.8 


V 


Voutput-Rangc 


Allowable driver output voltage 
range with respect to GND 


0 




2.8 


V 


Vqd + 


Driver differential output high 
voltage 


0.S 






"v 


Vor>. 


i fferential output low 

voltapc 






-0.5 


V 


Vir + 


Receiver differential input high 
thieshold voltage 






10 


mV 


Vrr- 


Receiver differential input low 
threshold voltage 


-10 






oiV 


Vlnpui-Range 


Allowable receiver input voltage 
range with respect to GND 


0 




3.0 


V 


I in 


Input leakage current (excluding 
hibernate bias) 


-25 




25 


uA 



[00608] The electrical parameters and characteristics of the differential line drivers and line 

receivers are described in. Table VIIL - Functionally, the driver transfers the logic level on 
the input directly to a positive output, and the inverse of the input to a negative output. The 
delay from input to outputs is well-matched to the differentia] line which is driven 
differentially. In most implementations, the voltage swing on the outputs is less than the. 
swing on the input to minimize power consumption and electromagnetic emissions. Table 
VIII presents a minimum voltage swing to be around 0.5V. However, other values can be 
used, as would be known by those skilled in the art, and the inventors contemplate a smaller 
value in some embodiments, depending on design constraints. 
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[00609] The differential line receivers have the same characteristic as a .high-speed voltage 

comparator. In FIG. 41, the input without the bubble is the positive input arid the input with 
the bubble is the negative input. The output is a logic one if: (Vinput+) - (Vinput-) is 
greater than zero. Another way to describe this is a differential amplifier with very large 
(virtually infinite) gain with the output clipped at logic 0 and 1 voltage levels. 

[00610] The delay skew between different pairs should be minimized to operate the 

differential transmission System at the highest potential speed. 

[00611] In FIG. 42, a host controller 4202 and a client or display controller 4204 are shown 

transferring packets over the communication link 4206. The host controller employs a 
series of three drivers 4210, 4212, and 4214 to receive the host DATA and STB signals to 
be transferred, as well as to receive the client Data signals to be transferred.. The driver 
responsible for passage of the host DATA employs an enable signal input to allow 
activation of the communication link generally only when transfer from the host to the 
client is desired. Since the STB signal is formed as part of the transfer of data, no 
additional enable signal is employed for that driver (4212), The outputs of each of the 
DATA and STB drivers are connected to termination impedances or resistors 4216a, 421 6b, 
42t6.c, arid 4216d, respectively. 

[00612] ' Termination resistors 4216a and 4216b will also act as impedances on the input of 
the client side receiver 4220 for the STB signal processing while additional termination 
resistors 421 6e and 42161" are placed in series with resistors 4216c and 4216d, respectively 
on the input of the client data processing receiver 4222. A sixth driver 4226 in the client 
controller is used to prepare the data signals being transferred from the client: to the host, 
where driver 4214, through termination resistors 4216c and 4216d, on the input side, 
processes the data for transfer to the host for processing. 

[00613] Two additional resistors 4218a and 4218b are placed between the termination 

resistors and pound and a voltage source 4220, respectively, as part of the hibernation 
control discussed elsewhere. The voltage source is used to drive the transfer lines to the 
high or low levels previously discussed to manage the flow of data. 

[00614] The above drivers and impedances can be formed as discrete components or as part 

of a circuit module, or an application specific integrated circuit (ASIC) which acts as a 
more cost effective encoder or decoder solution. 

[00615] It can be easily seen that power is transferred to the client device, or display, from 

the host device using the signals labeled MDDIJPwr and MDDI_Gnd over a pair of 
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conductors. The MDDI_Gnd portion of the signal acts as the reference ground and the 
power supply return path or signal for the display device. The MDDI_Pwr signal acts as 
the display device power supply which is driven by the host device hi an exemplary 
configuration, for low power applications, the display device is allowed to draw up to 500 
mA. The MDDI_Pwr signal can be provided from portable power sources, such as but not 
limited to, a lithium-ion type battery- or battery pack residing at the host device, and may 
range from 3.2 to 4.3 volts with respect to MDDI_Gnd. 

VII. Timing Characteristics 
A. Overview 

[00616] The steps and signal levels employed by a client to secure service from the host and 

by the host to provide such services are illustrated in FIG. 43. In FIG. 43, the first part of 
signals being illustrated shows a Link Shutdown Packet being transferred from the host and 
the data line is then driven to a logic zero state using the high-impedance bias circuit* No 
data is being transmitted by the client display, or host, which has its driver disabled. A 
series of strobe pulses for the MDDI_Stb signal line can be seen at the bottom, since 
MDDIJStb is active during the Link Shutdown Packet. Once this packet ends and the logic 
level changes to zero as the host drives the bias circuit and logic to zero, the MDDLStb 
signal line changes to a logic-zero level as well. This represents the termination of the last 
signal transfer or service from the host, and could have Occurred at any time in the past, and 
is included to show the prior cessation of service, and the state of the signals prior to service 
commencement. If desired, such as signal can be sent just to reset the communication link 
to the proper s»ato v»ith<>ui a 'known' prior communication having been undertaken by this 
host device. 

[00617J As shown in FIG. 43, the signal output from the client is initially set at a logic level 

of zero. In other words, the client output is at a high impedance, and the driver is disabled. 
When service is being requested, the client enables its driver and sends a service request to 
the host, which is a period of time, designated tservice, during which the line is driven to a 
logic one level, A certain amount of time then passes or may be needed before the host 
detects the request, termed most-detect, .after which the host responds with a link startup 
sequence by driving the signal to a logic one level. At this point, the client de-asserts the 
request, and .disables the service request driver so that the output line from the client goes to 
a zero logic level again. During. this time, the MDDIJStb signal is at a logic zero level. 
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[0061:8] The host drives the host data output at the T level for a period termed, trestart-high, 

after which the host drives the logic level to zero and activates MDDI_Stb for a period 
termed tres tart-low, after which the first forward traffic begins with a Sub-Frame Header 
Packet, and the forward traffic packets' are then transferred. The MDDIJStb signal is active 
during the tres tart-low period and the subsequent Sub-Frame Header Packet. 

[006 1 9] Table VDI shows representative times for the length of the various periods discussed 

above, and the relationship to exemplary minimum and maximum data rates, where: 



Link_.Data._Rate 



Table Vm 



Parameter 


Description 


Min. 




Max, 


Units 


tservice 


Duration of display service 
request pulse 


60 


70 


80 


psec ; 


ttestart-higb 


Duration of host link restart 
high pulse 


140 


150 


160 


Jisec 


trcalart-low 


Duration of host link restart 
low pulse 


40 


50 


60 


usee 


tdisplay-detoct 


Time for display to detect 
link restart sequence 






50 
50 


fxsec 
j^sec 


thost-detect 


Time for host to detect 


1 


1/tbit-niin-perf 


Link data rate for a minimum 
performance device 


0.001 






Mhps 


l'/tbit-ronx-perf 


Maximum link data rate 
range for a device 


0.001 




450 


Mbps 




Reverse Link data rate 


0.0005 






fblt 


Period of one forward link 
data bit 




10 & 


nscc 



[00620] Those skilled in the ait will, readily understand that, the functions of the individual 

elements illustrated in FIGS, 41 and 42, are well known, and the function of the. elements in 
FIG. 42 is confirmed fay the timing diagram in FIG, 43, Details about the series 
terminations and hibernation resistors that are shown in FIG. 42 were omitted from FIG. 41. 
because that information is unnecessary for a description of how to perform die Data-Strobe 
encoding and recover the clock from it. 



WO 2005/018191 



PC171TS2004/026264 



108 

B. Data-Strobe Timing Forward Link 

[00621] The switching characteristics for the transfer of data on the forward link from the 

host driver output is shown in Table IX. Table IX presents a tabular form of the minimum 
and maximum desired, versus typical times for certain signal transitions to occur. For 
example, the typical length of time for a transition to occur from the start to the end of a 
data value (output of a '0' or T), a DataO to DataO transition, termed Udd-(host-output), is 
ttbit while the iriinimum time is about ttbit-0.5 Usee,, and the maximum is about ttbit * 0.5 
nsec. The relative spacing between transitions on the DataO, other data lines (DataX), and 
the strobe lines (Stb), is illustrated in FIG. 44 where the DataO to Strobe, Strobe to Strobe, 
Strobe to DataO, DataO to non-DataO, non-DataO to. non-DataO, non-DataO to Strobe, and 
Strobe to non-DataO transitions are shown, which are referred to as ftds (host-output), ttss- 
(host-output), ttsd-(host-output), ttddx-(host-output), ttdxdx-(host-output), ltdxs-(host- 
output), and ttsdx-(host-output), respectively. 



Table IX 



Parameter 


Description 


. Min, 


Typ. 


Max. 


Units 


tfaJd-fliast-outpHt) 


DataO to DataO transition 


to -0.5 


. tat 


to + 0.5 


nsec 


ttd?-(hast-outpntl 


DataO to Strobe transition 


to -0.8 


to 


ttwt + 0.S 


nsec 


ttss-(hrat-on(putj 


,"h b>' nit" h 

transition 


ttwt - 0.5 


tet 


ttbit + 0.5 


nsec 


ttsd-aiost-ciutput) 


Strobe to DataO transition 


ttbit - 0.8 


ttbit 


tttit + 0.8 


nsec 


ttddx-(lu)st-ontput) 


DataO to non-DataO 
transition 










ttdxdx-(hiwt-output) 


non-DataO to non DataO 
transition 


Wt-0.5 


ttbit 


ttbit + 0.5 


nsec 


ttdxs-fliost-Oiitput) 


■non-DataO to Strobe 
transition 




ttbit 




nsec 


^tsfe-(host-output) 


Strobe to non-DataO 
transition 




ttbit 




nsec 



[00622] The typical MDDI timing requirements. for the client receiver inpul Jo- ihu s rme 
signals, transferring data on the forward link is shown in Table X. Since the same signals 
are being discussed but time delayed, no new figure is needed to illustrate the signal 
characteristics or meaning of the respective labels, as would be understood by those skilled 
in the art. 
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Fable x 



Parameter 


Description 


Min. 


>?!>• 


Max. 




ttdd-(dispkv-kiput) 


DataO to DataO transition 


tnrit-1.0 


ttbit 


tt W t + i.o 


nsec 


ttds-jaisplay- input) 


Hi to Sirots j r .ti t 


tttit- 1.5 


ttbit 


ttbit + 1.5 


nsec 


ttss-(dl splay-Input) 


Strobe to Strobe transition 


tea- 1.6 


ttbit 


ttbit + 1.0 


mco 


ttsd-(dis|]!ay-iiigiit) 


Strobe to DataO transition 


ttbit .-1.5 


w 


ttbit +L5 


usee 


tlAJMhosl-oirtpot) 


DataO to non-DataO transition 




ttbit 






ttdxdx-(host-oiiipufj 


non-DataO to non-DataO 
transition 




ttbit 




nsec 


tfdx3-{hrat-outpiit) 


non-DataO to Strobe 
transition 




ttbit 




nsec 


t(Bdx-(host-output) 


Strobe to non DataO 
transition 




ttbit 







£00623] FIGS, 45 and 46 illustrate the presence Of a delay in response that can occur when 

the host disables or enables the host driver, respectively, In the case of a host forwarding 
certain packets, such as the Reverse link Encapsulation Packet or the Round Trip Delay 
Measurement Packet, the host disables the line driver after the desired packets are 
forwarded, such as the Parameter CRC, Strobe Alignment, and All Zero packets illustrated 
in FIG. 45 as having been transferred. However, as shown in FIG. 45, the state of the line 
does not necessarily switch from '0' to a desired higher value instantaneously, although this 
is potentially achievable with certain control or circuit elements present, but takes a period 
of time termed the host Driver Disable Delay period to respond. While it could occur 
virtually instantly such that this time period is 0 nanoseconds (nsec.) in length, it could 
more readily extend over some longer period with 10 nsec. being a desired maximum 
period length, which occurs during the Guard Time 1 or Turn Around 1 packet periods. 

[00624] Looking in FIG. 46, one sees the signal level change undergone when the host 
Driver is enabled for transferring a packet such as the Reverse link Encapsulation Packet or 
the Round Trip Delay Measurement Packet. Here, after the Guard Time 2 or Turn Around 
2 packet periods, the host driver is enabled and begins to drive a level, here '0', which value 
is approached or reached over a period of time termed the Host Driver Enable Delay period, 
which occurs during the Driver Re-enable period, prior to the first packet being sent. 

[00625] A similar process occurs for the drivers- and signal transfers for the client device, 

here a display. The general guidelines for the length of these periods, and their respective 
relationships are shown in Table XI, below. 
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Table SI 



Description 


Mj,b. 


Max. 
10 


Unite- 
nsec 


Host Driver Disable Delay 


0 


Host Driver Enable Delay 


0 


2.0 


nsec 


Display Driver Disable Delay 


0 


10 


nsec 


Displ ay Driver Enable Delay 


0 


2.0 





C. Data-Strobe Timing Reverse Link 

[00626] The switching characteristics and timing rel 

used to transfer data on the reverse link from the el; 
and 48. The typical times for certair 
illustrates the relationship at the host r 
transferred and the leading and trailing 
to as the set-up time for the rising or lea 



time foe 
these se 



on ships for the data and strobe signals 
it driver output are shown in FIGS. 47, 
transitions are discussed below. FIG. 47 
input between the timing of the data; being 
' the strobe pulses. That is, what is referred 
*e of the strobe si pals, tsu-sr and the set-up 
signals, tsu-sf. A typical length of time for 



iriods i 
fflut 



on the 



7] FIG. 41 

delay developed by the reverse data ti 
between the timing of the data being to 
strobe pulses accounting for induced del 
delay between the rising or leading edg< 



taracteristics and corresponding client output 
5. In FIG. 48, one can see the relationship 
ared and the leading and trailing edges of the 
That is, what is referred to as the propagation 
the strobe signals and the data (valid), tpd-sr, 
and the propagation delay between the data and the trailing or falling edge of the strobe 
signals, tpd-sf. A typical maximum length of time for these propagation delay periods is on 
the order of S nanoseconds. 



VJ1! ! '>ii< » * « not Lif » V \hi ,)| en ion) 

A, State Machine Packet Processor 

[00628] Packets being transferred over a MDD1 link are dispatched very rapidly, typically at 

a rate on the order of 300 Mbps or more, such as 400 Mbps, although lower rates are 
certainly accommodated, as desired. This type of bus or transfer link speed is too great for 
currently commercially available (economical) general-purpose microprocessors or the like 
to control. Therefore, a practical implementation to accomplish this type of signal transfer 
is to utilize, a programmable state machine to parse the input packet stream to produce 
packets that are transferred or redirected to the appropriate audio-visual subsystem for 
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which they are intended. Such devices are well known and use circuits generally dedicated, 
to a limited number of operations, functions, or states to achieve a desired high speed or 
very high speed operation. 

[00629] General purpose controllers, processors, or processing elements, can be used to 

more appropriately act upon or manipulate some information such as control or status 
packets, which have lower speed demands. When those packets (control, status, or other 
pre-defined packets) are received, the state machine should pass them through a data buffer 
or similar processing element to the general-piupose processor so the packets can be acted 
upon to provide a desired result (effect) while the audio and visual packets are transferred to 
their appropriate destination for action. If future, microprocessors or other general purpose 
controllers,, processors, or processing elements are manufactured to achieve higher data rate 
processing capabilities, then the states or state machine discussed below might also be 
implemented using software control of such devices, typically as programs stored on a 
storage element or media. 

[00630] The general purpose processor function can be realized in some embodiments by 
taking advantage of the processing power, or excess cycles available for, microprocessors 
(CPUs) in computer applications, or controllers, processors, digital signal processors 
(DSPs), specialized circuits, or ASICs found in wireless devices, in much the same manner 
as some modems or graphics processor's utilize the processing power of CPUs found in 
computers to perform some functions and reduce hardware complexity and costs. However, 
this cycle sharing or usage can negatively impact the processing speed, timing, or overall 
operation of such elements, so in many applications, dedicated circuits or elements are 
preferred for this general processing. 
[00631] In order for image data to be viewed .on a display (micro-display), or to reliably 

receive all packets sent by the host device, the display signal processing is synchronized 
with the forward link channel timing. That, is, signals arriving at the display and the display 
circuits need to be substantially time synchronized for proper signal processing to occur. A 
high level diagram of states achieved by signal processing steps or a method by which such 
a synchronization can be ' implemented is presented in the illustration of FIG. 49. In 
FIG. 49, the possible forward link synchronization "states" for a state machine 4900 are 
shown being categorized as one ASYNC FRAMES STATE 4904, two ACQUIRING 
SYNC STATES 4902 and 4906, and three IN-SYNC STATES 4908, 4910, and 4912. 
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[00632] As shown by starting step or state 4902, the display or client, such as a presentation 
device, starts in a pre-selectcd "iio sync" state, and searches for a unique word, in the Erst 
sub-frame header packet that is detected. It is to be noted that this no sync state represents 
the minimum communication setting or "fall-back" setting in which a Type I interface is 
selected. When the unique word is found during the search, the display saves the sub-frame 
length field. There is no checking of the CRC bite for processing on this first frame, or until 
synchronization is obtained, If this sub-frame length is zero, then sync state processing 
proceeds accordingly to a state 4904 labeled here as the "async frames" state, which 
indicates that synchronization has not yet been achieved. This step in the processing is 
labeled as having encountered eond 3, or condition 3, in FIG. 49. Otherwise, if the frame 
length is greater than aero, then the sync state processing proceeds to a state 4906 where the 
interface state is set as "found one sync frame." This step in the processing is labeled as 
m <Mit>Hi ' >n r k i mi i ' in FIG. 49. In addition, if the state machine sees a 
frame header packet and good CRC determination for a frame length greater than zero, 
processing proceeds to the "found one sync frame" state. This is labeled as meeting cond 6,. 
or condition 6, in FIG. 49. 

[00633] In each situation in which the system is in a state other than "no syne", when the 
unique word is detected and a good CRC result is determined for the sub-frame header 
packet, and the sub-frame length is greater than zero, then the interface state is changed to 
the "in-sync" state 4908. This step in the processing is labeled as having encountered cond 
1, or condition 1, in FIG. 49. On the other hand, if either the unique word or the CRC in the 
sub-frame Header Packet are not correct, then the sync state processing proceeds or returns 
to the interface state 4902 of "NO SYNC FRAME" state. This portion of the processing is 
labeled as encountering cond 2. or condition 2, in the state diagram of FIG. 49. 

B. Acquisition Time for Sync 

[00634]- The interface can be configured to accommodate a certain number of "sync errors" 
prior to deciding that synchronization is lost and returning to the "NO SYNC FRAME" 
state. In FIG. 49, once the state machine has reached the "IN-SYNC STATE" and no errors 
are found, it is continuously encountering a cond 1 result, and remains in the ' IN-SYNC" 
state. However once one cond 2 result is detected, processing changes- the state to a "'one- 
sync-error" state 4910. At this point, if processing results in detecting another cond 1 
result, then the state machine returns to the "ifrsync" -state, otherwise it encounters another 
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cond 2 result, and moves to a "TWO-SYNC-ERRORS" state 4912. Again, if a cond I 
occurs, processing returns the state machine to: the "IN-SYNC" state. Otherwise, another 
cond 2 is encountered and tile state machine returns to the "no-sync" state. It. is also 
understandable that should 'the interface encounter a "link shutdown packet", then this will 
cause the link to terminate data transfers and return to the "no-sync frame" state as there is 
nothing to synchronize with, which is referred to as meeting cond 4, or condition 4, in the 
state diagram erf FIG. 49. 

[00635] It is understood that it is possible for there to be a repeating "false copy 3 ' of the 
unique word which may appear at some fixed location within the sub-frame. In that 
situation, it is highly unlikely that the state machine will synchronize to the sub-frame 
because the CRC on the sub-frame Header Packet must also be valid when processed in 
order for the MDD interface processing to proceed to the "1 N SYNC" state. 

[00636] The sub-frame length in the sub-frame Header Packet may be set to zero to indicate 
that the host will transmit only one sub-frame before the link is shut down, and. the MDD 
interface is placed in or configured into an idle hibernation state, Tn this case, the display 
must immediately receive packets over the forward link after detecting the sub-frame 
Header Packet because only a single sub-frame is sent before the link transitions to the idle 
state. In normal or typical operations, the sub-frame length is non-zero and the display only 
processes forward link packets while the interface is in those states collectively shown as 
"IN-SYNC" states in FIG. 49. 

[00637] The time required for a display to synchronize to the forward link signal is variable 

depending on the sub-frame size and the forward link data rate. The likelihood of detecting 
a "false copy" of the unique word as part of the random, or more random, data in the 
forward link is greater when the sub-frame size is larger. At the same time, the ability to 
recover from a false detection is lower, and the time taken to do so is longer, when a 
forward link data rate is slower. 

C, Initialization 

[00638] As slated earlier, at the time of "start-up", the host configures the forward link to 

operate at or below a minimum required, .or desired, data rate of 1 Mbps, and configures the 
sub-frame length and media-frame rate appropriately for a given application. That is, both 
the forward and reverse links begin operation using the Type-l interface. These parameters 
are generally only going to be used temporarily while the host determines the capability or 
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desired configuration for the client display (or other type of client device). The host sends 
or transfers a sub-frame Pleader Packet over the forward link followed by a Reverse Lint 
Encapsulation Packet which has bit of the Request Flags set to a value of one (1), in 
order to request that the display or client responds with a Display Capability Packet. Once 
the display acquires synchronization on (or with) the forward link, it sends a Display 
Capability Packet and a Display Request and Status Packet over the reverse link or channel. 
[00639] The host examines the contents of the Display Capability Packet in order to 

determine how to reconfigure the link for optimal or a desired level of performance. The 
host examines the Protocol Version and Minimum Protocol Version fields to confirm mat 
the host and display use versions of the protocol that are compatible with each other. The 
protocol versions: generally remain as the first two parameters of the display capability 
Packet so that compatibility can be determined even when other elements of the protocol 
might not be compatible or completely understood as being compatible. 

D. CRC Processing 

[00640] For all packet types, the packet processor state machine ensures that the CRC 
checker is controlled appropriately or properly. It also increments a CRC error counter 
when a CRC comparison results in one or more errors being detected, and it resets the CRC 
counter at the beginning of each sub-frame being processed. 

E. Alternative Loss Of Synchronization Check 

[00641] While the above series of steps or states work to produce higher data rates or 

throughput speed, Applicants have discovered that an alternative arrangement or change in 
the conditions the client uses to declare that there is a loss of synchronization with the host, 
can be used effectively to achieve even higher data rates or throughput. The new inventive 
embodiment has the same basic structure, but with the conditions for changing states 
changed. Additionally a new counter is implemented to aid in making checks for sub-frame 
synchronization. These steps and conditions are presented relative to FIG. 63, which 
illustrates a series of states and conditions useful in establishing the operations of the 
method or state machine. Only the "ACQUTRING-SYNC STATES" and TN-SYNC 
STATES" portions are shown for clarity. En addition, since the resulting states are 
substantially the same, as is the state machine itself, they use the same numbering. 
However, the conditions for changing states (and the state machine operation) vary 
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somewhat, so that all are renumbered for clarity between the two figures (1, 2, 3, 4, 5, and 
6, versus 61, 62, 63, 64, and 65), as a convenience in identifying differences. Since the 
ASYNC FRAME state is not considered in this discussion, one state (4904) and condition 
(6) are no longer used in the figure. 

[00642] In FIG. 63, the system or client (for display or presentation) starts with state 

machine 5000 in the pre-selected "no sync" state 4902, as in FIG. 49. The first state change 
for changing states from the ho-sync condition 4902 is in condition 64 which is the 
discovery of the sync pattern. Assuming that the CRC of the sub-frame header also passes 
on this packet (meets condition 61), the state of the packet processor state machine can be 
changed to the in-sync state 4908, A sync error, condition 62, will cause the state machine 
to shift to state 4910, and a second occurrence to state 4912. However, it has been 
discovered that any CRC failure of an MDDI packet will cause the state machine to move 
out of in-sync state 4908, to the one sync error state 4910. Another CRC failure of any 
MDDI packet will cause a move to the two sync failure state 4912. A packet decoded with 
a correct CRC value will cause the state machine to return to the in-sync state 4908. 

[00643] What has been changed is to utilize the CRC value or determination for 'every' 

packet That is, to have the state machine, look at the CRC value, for every packet to 
determine a loss of synchronization instead of just observing sub-frame header packets. In 
this configuration or process, a loss of synchronization is not determined using the unique 
word and just sub-frame header CRC values. 

[00644] This new interface implementation allows the MDD interface link to recognize 

synchronization failures much more quickly, and, therefore, to recover from them more 
quickly, as well. 

[00645] To make this system more robust, the client should also add or utilize a sub-frame 

counter. The client then checks for the presence of the unique word at the time it is 
expected to arrive or occur in a signal. If the unique word does not occur at the correct 
time, the client can recognize that a synchronization failure has occurred much more 
quickly than if it had to wait several (here three) packet times or periods that were greater 
than a sub-frame length. If the test for the unique word indicates it is not present, in other 
words that the timing is incorrect, then the client can immediately declare a link loss of 
synchronization and move to the no-sync state. The process of checking for the proper 
unique word presence, adds a condition 65 (cond 65) to the state machine saying that the 
unique word is incorrect. If a sub-frame packet is expected to be received on the client and 
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doesn't match up, the client can immediately go to the no-sync state 4902, saving additional 
time waiting for multiple sync errors (condition 62) normally encountered traversing 
through states 4910 and 4912. 
[00646] This change uses an additional counter or counting function in the client core to 
count sub-frame- length. In one embodiment, a count down function is used and: the transfer 
of any packet that was currently being processed is interrupted to check for the sub-frame 
unique word if the counter has expired. Alternatively, the counter can count up, with the 
count being compared to a desired maximum or particular desired value, at which point the 
current packet is checked. This process protects the client from decoding packets that arc 
incorrectly received on the client with extraordinarily long packet lengths. If the sub-frame 
length counter needed to interrupt some other packet that was being decoded, a loss of 
synchronization can be determined since no packet should cross a sub-frame boundary. 

IX. Packet Processing 
[00647] For each type of packet discussed above that the state machine receives, it 
undertakes a particular processing step or series of steps to implement operation of the 
interface. Forward link packets are generally processed according to the exemplary 
processing listed in Table XII below. 



Table XII 



Packet type 


Packet processor state machine response 


Sub-Frame Header (SH) 


Confirms good packet, captures sub -frame 
length field, and sends packet parameters 
to a general purpose processor. 


Filler (F) 


rc dA . 


Video Stream (VS) 


Interprets the Video Data Format 
Descriptor and other parameters, unpacks 
packed pixel data when necessary, 
translates pixels through the color map if 
necessary, and writes pixel data to 
appropriate locations in the bitmap. 


Audio Stream (AS) 


Sends audio sample rate setting to audio 
sample clock generator, separates audio 
samples of specified size, unpacks audio 
sample data when necessary, and routes 
audio samples to appropriate audio sample 
FIFO 


Color Map (CM) 


Reads color map size and offset 
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Packet type 


Packet processor state machine re.-; 1 




parameters, and writes the color map data 
to a color map memory or storage Location. 


\ Reverse Link Encapsulation (EEL) 


Facilitates sending packets in reverse 
direction at the appropriate time. Reverse 
link flags are examined, and Display 
Capability packets are sent as necessary. 
Display Request and Status packets are 
also sent as appropriate. 


Display Capability (DC) 


Sends this type of packet when requested 
by a host using the reverse link flags, field 
of the Reverse Link Encapsulation Packet. 


.Keyboard (K) 


Passes these packets to and from a general 
purpose processor that communicates with 
a keyboard type device, if one is present, 
and use is desired. 


Pointing Device (PD) 


Passes these packets to and from a general 
purpose processor that communicates with 
a pointing type device, if one is present, 
and use is desired. 


Link Shu tdown (LS) 


Records fact link is shut down and informs 
a general-purpose processor. 


Display Service Request and Status 
(DSRS) 


Sends this packet as the first packet in the 
Reverse Link Encapsulation packet. 


Bit Block Transfer (BPT) 


Interprets packi pi leten such as Video 
Data Format Descriptor, determines which 
pixels to move first, and moves pixels in 
bitmap as required. 


Bitmap Area Fill (BAF) 


Interprets packet parameters, translates 
pixels through color map if necessary, and 
writes pixel data to appropriate locations in 
bitmap, 


Bitmap Pattern Fill (BPF) 


Interprets packet parameters, unpacks 
packed pixel data if necessary, translates 
pixels through color map if necessary, and 
writes pixel data to appropriate locations in 
bitmap. 


Communication Link Channel (CLC) 


Sends- this data directly to a general- 
purpose processor. 


Display Service Request (DSR) during 
hibernation 


General-purpose processor controls the 
low-level functions of sending request and 
detects contention with link restarting on 
its own. 


Interface Type Handoff Request 
(1THR) and Interface Type 
Acknowledge (1TA) 


May pass these packets to and from the 
general-purpose processor. The logic to 
receive this type of packet and formulate a 
response with an acknowledgment is 
substantially minimal. Therefore, this 
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Packet type 


Packet processor state machine n.rp:)v.ss 




operation could also be implemen ted 
within the packet processor state machine. 
The resulting handoff occurs as a low-level 
physical layer action and is not likely to 
affect the functionality or functioning of 
the general-ptirpose processor. 


Perform Type Handoff (PTH) 


May act on such packets either directly or 
by transferring them to the general-purpose 
processor, also commanding hardware to 
undergo a mode change. . 



X. Reducing the Reverse Link Data Mate 

[00648] It has been observed by the inventors that certain parameters used for the host link 

controller can be adjusted or configured in a certain manner in order to achieve a maximum 
or more optimized (scale) reverse link data rale, winch is very desirable. For example, 
during the time used to transfer the Reverse Data Packets field of the Reverse Link 
Encapsulation Packet, the MDDI_Stb signal pair toggles to create a periodic data clock at 
half the forward link data rate. This occurs because the host link controller generates the 
MDDLJStb signal that corresponds to the MDDI_DataO signal as if it were sending all 
zeroes. The MDDI_Stb signal is transferred from the host to a client where it is used to 
generate a clock signal for transferring reverse link data from the display, with which, 
reverse data is sent back to the host. An illustration of typical amounts of delay 
encountered for the signal transfer and processing on the forward and reverse paths in a 
system employing the MODI, is shown in HQ. 50. In FIG. 50, a series of delay values 1,5 
nsec., 8.0 usee., 2.5 nsec., 2.0 nsec., 1.0 nsec, 1.5 nsec, S.O nsec, and 2,5 nsec,, are shown 
near processing portions for the Stb+/- generation, cable transfer-to-display, display 
receiver, clock generation, signal clocking, DataG-W- generation, cable transfer-to-host, and 
host receiver stages, respectively. 

[00649] Depending on the forward link data rate and signal processing delays encountered, it 

may require more time than one cycle on the MDDIjSfb signal for this "round trip" effect 
or set of events to be completed, which results in the consumption undesirable amounts of 
time or cycles. To circumvent .this problem, the Reverse Rate Divisor makes it possible for 
one bit time on the reverse link to span multiple cycles of the MDDI_Stb signal. This 
means that the reverse link data rate is less than the forward link rate. 
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[00650] It should be noted that the actual length of signal delays through the interface may 

differ depending on each specific host-client system or hardware being used. Although not 
required, each system can generally be made to perform better by using the Round Trip 
Delay Measurement Packet to measure the actual delay in a system so that the Reverse Rate 
Divisor can be set to an optimum value. 

[00651] A round-trip delay is measured by having the host send a Round Trip Delay 

Measurement Packet to the display. The display responds to this packet by sending a 
sequence of ones back to the host inside of, or during, a pre-selected measurement window 
in that packet called the Measurement Period field. The detailed timing of this 
measurement was described previously. The round-trip delay is used to determine the rate 
at which the reverse link data can be safely sampled. 

[00652] The round-trip delay measurement consists of determining, detecting, or counting 

the number of forward link data clock intervals occurring between the beginning of the 
Measurement Period field and the beginning of the time period when the Oxff, Oxff, 0x00 
response sequence is received back at the host from the client. Note that it is possible that 
the response from the client could be received a small fraction of a forward link clock 
period before the measurement count was about to increment. If this unmodified value is 
used to calculate the Reverse Rate Divisor it could cause bit errors on the reverse link due 
to unreliable data sampling. An example of this situation is illustrated in FIG. 51, where 
signals representing MDDIJData at host, MDDI Stb at host, forward link data clock inside 
the host, and a Delay Count are illustrated in graphical form. In FIG. 51, the response 
sequence was received from the display a fraction of a forward link clock period before the 
Delay Count was about to increment from 6 to 7. If the delay is assumed to be 6, then the 
host will sample the reverse data just after a bit transition or possibly in the middle of a bit 
transition. This could result in erroneous sampling at the host. For this reason, the 
measured delay should typically be incremented by one before it is used to calculate the 
Reverse Rate Divisor. 

[00653] The Reverse Rate Divisor is the number of MDDLSth cycles the host should wait 

before sampling the reverse link data. Since. MDDLStb is. cycled at a rate that is one half 
of the forward link rate, the corrected round-trip, delay measurement needs to be divided by 
2 and then rounded up to the next integer. Expressed as a formula, this relationship is: 
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V 2 } 

For the example given, this becomes: 

reverse _ rate _ divisor - RoundUpfoNexlMeger^ -j-j = 4 

[00654] If the round trip delay measurement used in this example were 7 as opposed to 6, 

then the Reverse Rate Divisor would also be equal to 4. 

[00655] The reverse link data is sampled by the host on the rising edge of the Reverse Link 

Clock, There is a counter or similar known circuit or device present in both the host and 
client (display) to generate the 'Reverse Link CJock. The counters an. i n i, ■ IsoUm ,w 
first rising edge of the Reverse Link Clock occurs at the begiiming of the first bit in the 
Reverse Link Packets field of the Reverse Link Encapsulation packet. This is illustrated, 
for the example given below, in FIG. 52. The counters increment at each rising edge of the 
MDDI_Stb signal, and the number of counts occurring until they wrap around is set by the 
Reverse Rate Divisor parameter in the Reverse Link Encapsulation Packet. Since the 
MDDT_Stb signal toggles at one half of the forward link rate, then the reverse link rate is 
one half of the forward link rate divided by the Reverse Rate Divisor. For example, if the 
forward link rate is 200 Mbps and the Reverse Rate Divisor is 4 then the reverse link data 
rate is expressed as: 



1 200Mbps . em „ 
- — 4 >. = 25Mbps 



[00656] An example showing the timing of the MDDLBataO and MDDl_Stb signal lines in 

a Reverse Link Encapsulation Packet is shown in FIG. 52, where the packet parameters 
used for illustration have the values: 



Packet Length = 1024 (OxMOO) 
Packet Type =65 (0x41) 
Reverse Link Flags = 0 



Turn Around 1 Length = 1 
Turn Around 2 Length = 1 
Reverse Rate Divisor = 2 
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Parameter CRC = 0xdb43 All Zero is 0x00 

Packet data between the Packet Length and Parameter CRC fields is: 

0x00, 0x04, 0x41, 0x00, 0x02, 0x01, 0x01, 0x43, Oxdb, 0x00, . , . 



[00657] The first reverse link packet returned from the display is the Display Request and 

Status Packet having a Packet Length of 7 and a packet type of 70. This packet begins with 
the byte values 0x07, 0x00, 0x46, ... and so forth. However, only the first byte. (0x07) is 
visible in FIG. 52. This first reverse link packet is time-shifted by nearly one reverse link 
'dock period in the figure to illustrate an actual reverse link delay. An ideal ■waveform with 
zero host to display round-trip delay is shown as a dotted-line trace. 

[00658] The MS byte of the Parameter CRC field is transferred, preceded by packet type, 
then the all zero field. The strobe from the host is switching from, one to zero and back to 
one as the data from the host changes level, forming wider pulses. As the data goes to zero, 
the strobe switches at the higher rate, only the change in data on the data line causes a 
change near the end of the alignment field. The strobe switches at the higher rate for the 
remainder of the figure: due to the fixed 0 or 1 levels of the data signal for extended periods 
of time, and the transitions falling on the pulse pattern (edge). 

[00659] The reverse link clock for the host Is at zero until the end of the Turn Around .1 
period, when the clock is started to accommodate the reverse link packets. The arrows in 
the lower portion of the figure indicate when the data is sampled, as would be apparent 
from the remainder of the disclosure. The first byte of the packet field being transferred 
(here 11000000) is shown commencing after Turn Around 1, and the line level has 
stabilized from the host driver being disabled. The delay in the passage of the first bit, and 
as seen for bit three, can bee seen in the dotted lines for the Data signal. 

[00660] In FIG. 53, one can observe typical values of the Reverse Rate Divisor based on the 
forward link data rate. The actual Reverse Rate Divisor is determined as a result of a 
round-trip link measurement to guarantee proper reverse link operation. A first region 5302 
corresponds to an area of safe operation, a .second region 5304 corresponds to an area of 
marginal performance, while a third region .5306. indicates settings that are unlikely to 
function properly. 

[00661] The round-trip delay measurement and Reverse Rate Divisor setting axe- the same 

while operating with any of the Interface Type settings on either the forward or reverse link 
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because they are expressed and operated on in terms of units of actual clock periods rather 
than numbers of bits transmitted or received. 

XI, Turn-Around and Guard Times 

[00662] As discussed earlier, the Tarn Around 1 field in the Reverse Link Encapsulation 

Packet and the Guard Time 1 field in the Round Trip Delay Measurement Packet designate 
values for lengths of time that allow for the host interface drivers to be disabled before the 
display interface drivers are enabled. Tarn Around 2 and Guard Time 2 fields provide time 
values which allow the display drivers to be disabled before the host drivers are enabled. 
The Guard Time 1 and Guard Time 2 fields are generally filled with pre-set or pre-sclccted 
values for lengths that are not meant to be adjusted. Depending on the interface hardware 
being, used, these values may be developed using empirical data and adjusted in some 
instances.to improve operation. 

[00663] Several factors contribute to a determination of the length of Turn Around 1 and 



these i 



MDDIJ 



drivers in the host. The maximum host driver disable time is specified in Table XI, where it 
shows that the drivers, take about 10 nsec maximum to disable and about 2 nsec. to enable. 
The minimum number of forward link clocks required for the host driver to be disabled is 
expressed according to the relationship: 



Clocks to disabh TA1 - - HostDrh?erDi$aMeDelay ^ 



[00664] The allowed value range of Turn Around 1 is expressed according to the 

relationship: 

{Clocks _to_ disab!e TM ^ 
— - — ' InteifaceType.r actor , w 



where the Interface Type Factor is 1 for Type-I, 2 for Type-H, 4 for Type-Ill, and 8 for 
Type-IV. 
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[00665] Combining the two equations from above, one can see that the Interface Type Factor 

term cancels out, and Turn Around 1 is defined as: 

Tu^Around^ReundUpToMxtln^ 

[00666] For example, a 1500 Mbps Type-Hi forward link would use a Turn Around 1 delay 

of: 

Turn _ Around = RoundUpToNextInteger ^ 500Mbp * ' 10 " sec j = 2 Bytes 

[00667] As the round trip delay increases, the timing margin improves from the point in time 

when the host is disabled to the time the display is enabled. 

[00668] The factors that determine the length of time generally used for Turn Around 2 are 
the forward link data rate, die maximum disable time of the MDDLData drivers in the 
display, and the round-trip delay of die communication link;. The calculation of the time 
required to disable the display driver is essentially the same as that for the host driver 
discussed above, and is defined according to the relationship: 



_ , J ,. torwardhinkDatoRate „. , _ ,„ . , , _ , 

Clocks _ to__ disaMe TA2 - — — • ■ • DtsplayDrrverDisableDelav^ 

hiteffaceTypeFactor^ ' 

and the allowed value range for Turn Around 2 is expressed as: 



Twn_Around_2 > RoundUpToMxtlntege 



Clecks_to_disable rAZ + rotmd_irip_delay+l 



Interface" fypeF ado fa 



) J 



[00669] For example, a 1500 Mbps Type-in forward link with a round-trip delay of 10 

fonvard link clocks typically uses, a Turn Around 2 delay on the order of: 
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Clocks _to_disaUe rA2 = 1500M ^ . 10wsec = 3.75 
4 



Turn _ Around _ 2 > ROundUpToNexilntegcr 



XII. Alternative Reverse Link Timing 

[00670] While the use of timing and guard bands discussed above work to achieve a high 

data transfer rate interface, the inventors have discovered a technique to allow for reverse 
bit lengths that are shorter than the round trip time, by changing the reverse timing 
discovery. 

[00671] As presented above, the previous approach to the timing of the reverse link is 

configured such that the number of clock cycles is counted from the last bit of the Guard 
Time 1 of a reverse liming packet until the first bit is sampled on the rising edge of an IO 
clock, That is the clock signal (s) used to time the inputs and outputs for the MDD interface. 
The calculation for the reverse rate divisor is then given by: 



reverse _ rate _ divisor - RoundUpToNextbiteger]^ rowu ^ ~ ~ . < MEL 



[00672] 'I'his provides a bit width equal to the round trip delay which results in a very 

reliable reverse- link. However, the reverse link has been shown to be capable of running 
faster, or at a higher data transfer rate, which the inventors want to take advantage of. A 
new inventive technique allows utilizing additional capabilities of the interface to reach 
higher speeds. 

[00673] This is accomplished by having the host count the number of clock cycles until a 

one is sampled, but with the host sampling the data line on both the rising and falling edges 
during the reverse timing packet This allows the host to pick the most useful or even 
optimal sampling point within the reverse bit to ensure that the bit is stable. That is, to find 
the most useful or optimal rising- edge to sample data on for reverse traffic reverse 
encapsulation packets. The optimal sampling point depends on both the reverse link divisor 
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and whether the first one was detected, on a rising edge or a falling edge. The new timing 
method allows the host to just look for the first edge of the QxFF GxFF 0x00 pattern sent by 
the client for reverse link timing to determine where to sample in a reverse encapsulation 
packet, 

[00674] Examples of the arriving reverse bit and how that bit would look for various reverse 

rate divisors, is illustrated in FIG. 64, along with a namber of clock cycles mat have 
occurred since the last bit of Guard Time 1. In Fig. 64, one can see that if tile first edge 
occurs between a rising and falling edge (labeled as rise/fall), the optimal sampling point 
for a reverse rate divisor of one, the optimal sample point is a clock cycle edge labeled V, 
as that is the only rising edge occurring within the period of the reverse bit. For a reverse 
rate divisor of two, the optima] sampling point is probably still clock cycle leading edge 'b' 
as cycle edge 'c' is closer to a bit edge than T>'. For a reverse rate divisor of four, the 
optimal sampling point is probably clock cycle edge 'd', as it is closer to the back edge of 
the reverse bit where the value has probably stabilized. 

[00675] Returning to FIG. 64, if, however, the first edge occurs between a falling and rising 
edge (labeled as fall/rise), the optimal sampling point for a reverse rate divisor of one is 
sampling point clock cycle edge r a', as that is the only rising edge within the reverse bit time 
period. For a reverse rate divisor of two. the optimal sampling point is edge 'b', and for a 
reverse rate divisor of four the optimal sampling point is edge 'c\ 

[00676] One can see that as the reverse rate divisors get larger and larger, the optimal 

sampling point becomes easier to ascertain or select, as it should be the rising edge that is 
closest to the middle. 

[00677] The host can use this technique to find the number of rising clock edges before the 

rising data edge of the timing packet data is observed on the data line. It can then decide, 
based on whether the edge occurs between a rising and falling edge or between a falling and 
rising edge, and what the reverse rate divisor is, how many additional clock cycles to add to 
a number counter, to reasonably ensure that the bit is always sampled as close to the middle 
as possible. 

£006781 Once the host has selected or determined the number of clock cycles, it can 
"explore" various reverse rate divisors with the client to determine: if a particular reverse 
rate divisor will work. The host (and client) can start with a divisor of one and check the 
CRC of the reverse status packet received from, the client to determine if this reverse rate 
functions appropriately to transfer data. If the CRC is corrupt, there is. probably a sampling 
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error, and the host can increase the reverse rate divisor and try to request a status packet 
again. If the second requested packet is corrupt, the divisor can be increased again and the 
request made again. If this packet is decoded correctly, this reverse rate divisor can be used 
for all future reverse packets. 

[00679] This method is effective and useful because the reverse timing should not change 

from the initial round trip timing estimate. If the forward link is stable, the client should 
continue to- decode forward link packets even if there are reverse link failures. Of course, it 
is still the responsibility of the host to set a reverse link divisor for the link, since this 
method does not guarantee a perfect reverse link. In addition, the divisor will depend 
primarily on the quality of the clock that is used to generate an IO clock. If that clock has a 
significant amount of jitter, there is a greater possibility of a sampling error. This error 
probability increases with the amount of clock cycles in the round trip delay. 

[00680] This implementation appeal's to work best for Type-I reverse data, but may present 

problems for Type-II through Type-IV reverse data due to the skew between data lines 
potentially being too great to run the link at the rate that works best for just one data pair. 
However, the data rate probably does not need to be reduced to the previous method even 
with Type-II through Type-IV for operation. This method may also work best if duplicated 
on each data line to select the ideal or an optimal clock sample location. If they are at the 
same sample time for each data pair, this method would continue to work. If they are at 
different sample periods, two different approaches may be used. The first is to select an 
desired or more optimized sample location for each data point, even if it is not the same for 
each data pair. The host can then reconstruct the data stream after sampling all of the bits 
from the set of data pairs: two bits for Type-n, four bits for Type-Ill, and eight bits for 
Type TV. The other option is for the host to increase the reverse rate divisor such that the 
data bits for every data pair can be sampled at the same clock edge. 

.XIII. Effects of Link Delay and. Skew 
[00681] Delay skew on the forward link between the MDDl_Data pairs and MDDI_Stb can 
limit the maximum possible data rate unless delay skew compensation, is used. The 
differences in delay that cause timing skew are due to the. controller logic, the line Olivers 
and receivers, and the cable and connectors as outlined below. 
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A. Link Timing Analysis Limited by Skew (MODI Type-I) 
J. Delay and Skew Example of a Type-l Link 

[00682] A typical interface circuit similar to that shown in .FIG. 41, is shown in FIG, 57 for 

accommodating a Type-I interface link. In FIG. 57, exemplary or typical values for 
propagation delay and skew are shown for each of several processing or interface stages of 
an MDDI Type-I forward link. Skew in the delay between MDDLStb and MDDLDataO 
causes the doty-cycle of the output clock to be distorted. Data at the D input of the receiver 
flip-flop (RXFF) stage using flip-flops 5728, 5732, must change slightly after the clock 
edge so that it can be sampled reliably. The figure shows two cascaded delay lines 5732a 
and 5732b being used to solve two different problems with creating this timing relationship. 
In the actual implementation these may be combined into a single delay element. 

[00683] Data, Stb, and Clock Recovery Timing on a Type-I Link for exemplary signal 

processing through the interface are illustrated in FIG. 58. 

[00684] The total delay skew that is significant generally arises or comes from the sum of 
the skew in the following stages: transmitter flip-flop (TXFF) with flip-flops 5704, 5706;, 
transmitter driver (TXDRVR) with drivers 5708, 5710; the CABLE 5702; receiver line 
receiver (RXRCVR) with receivers 5722, 5724; and receiver XOR logic (RXXOR). 
Delay 1 5732a should match or exceed the delay of the XOR gate 5736 in the RXXOR stage 
which is determined by the relationship: 

f TO -vM Ddiy 1) — f I'D -m>;( XOR ) 

[00685] It is desirable to meet this requirement so that the D input of receiver flip-flop 5728, 

5732 does not change before its clock input. This is valid if the hold-time of RXFF is zero. 

[00686] The purpose or function of Delay2 is to compensate for the hold-dme of the RXFF 

flip-flop according to the relationship: 

tpD-mniDeteyZ) ~ t B{HXFF) 

[00687] hi many systems this will be zero because the hold time is zero, and of course in that 

case the maximum delay of Delay2 can also be zero. 
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[00688] The: worst-case contribution to skew In the receiver XOR stage is in the data- 
late/strobe-early case where Delay 1 is at a maximum value and the dock output from the 
XOR gate comes as early as possible according to the relationship: 

' t PD-:mi\(XOR) 

[00689] In this situation, the data may change between two bit periods, n and n+1, very close- 

to the time where bit n+1 is clocked into the receiver flip-flop. 

[00690] The maximum data rale (minimum bit period) of an MDDI Type-J Hale is a function 

of the maximum skew encountered through all the drivers, cable, and receivers in the 
MDDI link plus the total data setup into the RXFF stage. The total delay skew in the link 
up to the output of the RXRCVR stage can be expressed as: 

t$KEW-YMXtUNK) = tsKEW-nwflXFFy + ^SKEW-imxiTXDSVSi ^SKEW-OBxiCABLE) + t SKEW-cmx(RXRCVR) 

and the minimum bit period is given by: 

^ff-rain = tsKEW-uuaiUNK) + 1 '$KEW-uwl{SXX0K) + f PD-wax(!>elay2) + hu{RXFF) 

In the example shown in FIG. 57, t SKE w-max([.iNK; = 1.4 nsec and the minimum bit 
period can be expressed as: 

W-Ma = 1-4 + 0.3 + 0.2 - 0.5 = 2.4n sec, or stated as approximately 416 Mbps. 

B. Link l iming Analysis for MDDI Type-II, III, and IV 
[00691] A typical interface circuit similar to that shown in FIGS. 41 and 57, is shown in 

FIG. 59 for accommodating Type-II, III, and IV interface links. Additional elements are 
used in the TXFF (5904), TXDRVR (5908), RXRCVCR (5922), and RXFF (5932, 5928, 
5930) stages to accommodate the additional signal processing. In FIG. 59, exemplary or 
typical values for propagation delay and skew are shown for each of several processing or 
interface stages of an MDDI Type-II forward link. In addition to skew in the delay between 
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MDDIJStb and MDDIJDataO affecting the duty-cycle of the output clock, there is also 
skew between botli of these two signals and the other MDDIJData signals. Data at the D 
input of the receiver flip-flop B (RXFFB) stage consisting of flip-flops 5928 and 5930, is 
changed slightly after the clock edge so it can be sampled reliably. If MDDIJDatal arrives 
earlier than MDDLStb or MDDIJDataO then MDDIJDatal should be delayed to be 
sampled by at least the amount of the delay skew. To accomplish this, data is delayed using 
the Delay3 delay line. If MDDIJDatal arrives later than MDDIJStb and MDDIJDataO and 
it is also delayed by Delay3 then the point where MDDIJDatal changes is moved closer to 
the next clock edge. This process determines an upper limit of the data rate of an MDDI 
Typc-Il, HI or IV link. Some exemplary different possibilities for the timing or skew 
relationship of two data signals and MDDIJStb with respect to each other is illustrated in 
FIGS. 60 A. 60B, and 60C. 
[00692] In order to sample data reliably in RXFFB when MDDIJDataX arrives as early as 
possible, Delay3 is set according to the relationship: 

* PD-ts\iR(Dekty2) ~ * SKEW -max( LINK) +t H(RXFFB) + { PD-me&CXOR) 

[00693] The maximum link speed is determined by the minimum allowable bit period. This 

is most affected when MDDIJDataX arrives as late as possible. In that case, the minimum 
allowable cycle time is given by: 

hm -tmn = ^ SKEW -max( I/.VA' ) + t PP-taa^Dalay3) + t SU(RXFFB) ~ t PD-mia{XOR) 

The upper bound of link speed is then: 

* PD-max(,Delayi) ~ ' PD-mm(Delay3) 

and given that assumption: 

^Bnr-aiailower-bound) 2 ' t SKEW-rmxiUNK} */'»-max(.Y(9R) + ^SU(KXFFB) ~^ hi (RXFFB} 
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[00694] In the example .given above, -the lower bound of the minimum bit period, is given by 
the relationship: 

*Hff-mh(i<»«r-te»rf) = 2 ■ i-4 + 1.5 + 0.5 + 0.1 = 4.8wsec, which is approximately 208 Mbps. 

[00695] This is much slower than the maximum data rate that can be used with a Type-I link. 

The automatic delay skew compensation capability of MDDI significantly reduces the 
affect that delay skew has on the maximum link rate 

XIV. Physical Layer Interconnection Description 

[00696] Physical connections useful for implementing an interface according to the present 
invention can be realized using commercially available parts such as part number 3260- 
SS2(01) as manufactured by Hirose Electric Company Ltd. on the host side, and part 
number 3240-SP-C as manufactured by Hirose Electric Company Ltd. on the display device 
side. An exemplary interface pin assignment or "pinout" for such connectors used with a 
Type-I/Type-H interfaces is listed in Table XIH, and illustrated in FIG. 61. 



Table XIII 



Signal Name j Pin 
i Number 


Color 


Sign nl Name 


Pin 
Number 


Color 


MDD1_ Pwr i 1 


White 


MDDI_ Gnd 


2 


Black paired wWhite 


MDDI_Stb+ 


3 


Green 


MDDI_Stl>- 


4 


Black paired w/Green 


MDDI_Data0+ 


7 


Blue 


"VIDDJ DataO- 


8 


Black paired w/Blue 


MDDI_Datal+ 


11 


Brown 


MDDJLPatal- 


12 


Black paired w/Bm 


MDDI Data2+ 


15 


Red 


MDDI_J>ata2 


16 


Black paired w/Red 


MDDI_Data3+ 


19 


Orange 


MDDl_Data3- 


20 


Black paired w/Org 


MDDI Data4+ 


17 


TBD1 


MDDI Data4- 


18 


Black paired w/TBD I 


MDDI_Data5+ 


13 


TBD2 


MDDI_Data5- 


14 


Black paired w/TBD2 


'MDDI_Data6+ 


9 


TB.D3 


MDDI Data6 


10 


Black paired w/TB.D3 


MDDiJData7+ 


5 


TBD4 


MDDI_Data7- 


6 


Black paired w/TBD4 




















Shield 







[00697] The shield is connected to the MDDl_Gnd in the host interface, and a shield drain 

wire in the cable is connected to the- shield of the display connector. However, the shield 
and drain wire are not connected to the circuit ground inside of a display. 
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[00698] Interconnection elements or devices are chosen or designed in order to be: small 

enough for use with mobile communication and computing devices, such as PDAs and 
wireless telephones, or portable game devices, -without being obtrusive or imaesthetic in 
comparison to relative device size. Any connectors and cabling should be durable enough 
for use in the typical consumer environment and allow for small size, especially for the 
cabling, and .relatively low cost. The transfer elements should accommodate data and 
strobe signals that are differential NRZ data having a transfer rate up to around 450Mbps 
for Type I and Type II and up to 3.6 Gbps for the 8-bit parallel Type IV version. 

[00699] For internal mode applications there are either no connectors in the same sense for 

the conductors being used or such connection elements tend to be very miniaturized. One 
example is zero insertion force "sockets" for receiving integrated circuits or elements 
housing either the host or client device. Another example is where the host and client 
reside on printed circuit boards with various interconnecting conductors, and have "pins" or 
contacts extending from housings which are soldered to contacts on the conductors for 
interconnection of integrated circuits. 

XV. Operation 

[00700] A summary of the general steps undertaken in processing data and packets during 
operation of an interface using embodiments of the invention is shown in FIGS. 54A and 
54B, along with an overview of the interface apparatus processing the packets in HG>. 5.5. 
In these figures, the process starts in a step 5402 with a determination as to whether or not 
the client and host ate connected using a communication path, here a cable. This can occur 
through the use of periodic polling by the host, using software or hardware that detects the 
presence of connectors or cables or signals at the inputs to the host, (such as is seen for USB 
interfaces), or othei t nov, n ecru : i[.ies. If there is no client connected to the host, then, it 
can simply enter a wait state of some predetermined length, depending upon the application, 
go into a hibernation mode, or be inactivated to await future use which might require a user 
to take action to reactivate the host. For example, when a host resides on a computer type 
device, a user might have to click on a screen icon or request a program that activates the 
host processing to look for the client. Again, simple plug in of a USB type connection, such 
as used for the Type-U interface, could activate host processing, depending on the 
capabilities and configuration of the host or resident host software. 
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[00701] Once' a client is connected to the host, or visa versa, or detected as being present, 

either the client or the host sends appropriate packets requesting service in steps 5404 and 
5406. The client could send either Display Service Request or Status packets in step 5404. 
It is noted that the link, as discussed above, could have been previously shut down or be in 
hibernation mode so this may not be a complete initialization of the communication link 
that follows. Once the communication link is synchronized and the host is trying to 
communicate with the client, the client also provides a Display Capabilities packet to the 
host, as in step 5408. The host can now begin to determine the type of support, including 
transfer rates, the client can accommodate. 
[00702] Generally, the host and client also negotiate the type (rate/speed) of service mode to 

be used, for example. Type I, Type U, Type II, and so forth, in a step 5410. Once the 
service type is established the host can begin to transfer information. In addition, the host 
may use Round Trip Delay Measurement Packets to optimize the timing of the 
cornmunication links in parallel with other signal processing, as shown in step 541 1 . 
[00703] As stated earlier, all transfers begin with a Sub-Frame Header Packet, shown being 
transferred in step 5412, followed by the type of data, here video and audio stream packets, 
and filler packets, shown being transferred in step 5414. The audio and video data will 
have been previously prepared or mapped into packets, and filler packets are inserted as 
needed or desired to fill out a required number of bits for the media frames. The host can 
send packets such as the Forward Audio Channel Enable Packets to activate sound devices:. 
In addition, the host can transfer commands and information using other packet types 
discussed above, here shown as the transfer of Color Map, Bit Block Transfer or other 
packets in step 5416. Furthermore, the host and client can exchange data relating to a 
keyboard or pointing devices using the appropriate packets. 
[00704] During operation, one of several different events can occur which lead to the host or 

cEent desiring a different data rate or type of interface mode. For example, a computer or 
other device communicating data could encounter loading conditions in processing data that 
causes a slow down in the preparation or presentation of packets. A display receiving the 
data could change from a dedicated AC power source to a more limited battery power 
source, and either not be able to transfer in data as quickly, process commands as readily, or 
not be able to use the same degree of resolution or color depth under the more limited 
power settings. Alternatively, a restrictive condition could be abated or disappear allowing 
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either device to transfer data at higher rates. This being more desirable, a request can be 
made to change to a higher transfer rate mode. 
[00705] If these or other types of known conditions occur or change, either the host or client 

may detect them and try to renegotiate the interface mode. This is shown fa step 5420, 
where the host sends Interface Type Handoff Request Packets to the client requesting a 
handoff to another mode, the client sends Interface Type Acknowledge Packets confirming 
a change is sought, and the host sends Perform Type Handoff Packets to make the change to 
the specified mode. 

[00706] Although, not requiring a particular order of processing, the client and host can. also 

exchange packets relating to data intended for or received from pointing devices, 
keyboards, or other user type input devices associated primarily with the client, although 
such elements may also be present on the- host side. These packets are typically processed 
using a general processor type element and not the state machine (5502). hi addition, some 
of the commands discussed above will also be processed by the general processor. (5504, 
5508) 

[00707] After data and commands have been exchanged between the host and client, at some 
point a decision is made as to whether or not additional data is to be transferred or the host 
or client is going to cease servicing the transfer. This is shown in step 5422. If the link is 
to enter either a hibernation state or be shut down completely, the host sends a Link 
Shutdown packet to the client, and both sides terminate the transfer of data. 

[00708] The packets being transferred in the above operations processing will be transferred 

using the drivers and receivers previously discussed in relation to the host and client 
controllers. These line drivers and other logic elements are connected to the state machine 
and general processors discussed above, as illustrated in the overview of PIG. 55. In Fig. 
55, a state machine 5502 and general processors 5504 and 5508 may further be connected to 
other elements not shown such as a dedicated USB interface, memory elements, or other 
components, residing outside of the link, controller with which they interact, including, but 
not limited to, the data source, and video control chips for view display devices. 

[00709] The processors, and state machine provide control over the enabling and disabling 

of the drivers as discussed above in relation to guard times, and so forth, to assure efficient 
establishment or termination of communication link, and transfer of packets. 
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XVI Display Frame Buffers 
[00710] Video data buffering requirements are different for moving video images compared 

to computer graphics. Pixel data is most often stored in a local frame buffer in the client so 

the image on the display can be refreshed locally. 

[00711] When full-motion video is being displayed (nearly every pixel in the display 

changes each Media Frame) it is usually preferred to store the incoming pixel data in one 

frame buffer while the image on the display is being refreshed from a second frame buffer. 

More than two display buffers may be used to eliminate visible artifacts as described below. 

When an entire image has been received in one frame buffer then the roles of the buffers 

can be swapped, and the newly received image is then used to refresh the display and the 

other buffer is filled with the next frame of the image. This concept is illustrated in FIG. 

91A, where pixel data is written to the offline image buffer by setting the Display Update 

bits to "01". 

[00712] In other applications the host needs to update only a small portion of the image 

without having to repaint the entire image. In this situation it is desired to write the new 
pixels directly to the buffer being used to refresh the display, as illustrated in detail FIG. 
91B. 

[00713] In applications that have a fixed image with a small video window it is easiest to 

write the fixed image to both buffers (display update bits equal to "1 1") as Shown in FIG. 
91C, and subsequently write the pixels of the moving image to the offline buffer by setting 
the display update bits to "01". 

[00714] The following rules describe the useful manipulation of buffer pointers while 

simultaneously writing new information to the client and refreshing the display. Three 
buffer pointers exist: current-fill points to the buffer currently being filled from data over 
the MDDI link. just_filled points to the buffer that was most recently Filled. 
being_displayed points to the buffer currently being used to refresh the display. All three 
buffer pointers may contain values from 0 to N-l where N is the number of display buffers, 
and N > 2. Arithmetic on buffer pointers is mod N, e.g. when N=3 and current fi 1 1=2. 
incrementing current_fill causes current_.fill to be set to 0. In the simple case where N=2, 
just_rll!ed is always the complement of current_fill. On every MDDI Media Frame 
boundary (Sub-frame Header Packet with the Sub-frame Count field equal so zero) perform 
the following operations in the order specified: set just_filled equal to current_fill, and set 
currentj'ilj equal to current Jill + 1. 
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[00715] MDDI Video Stream Packets update the buffers according to the structure or 
methodology of: when Display Update Bits equal to '01', pixel data is written to the buffer 
specified by currentjill; when Display Update Bits- equal to '00', pixel data is written to 
the buffer specified by just_filled; and when Display Update Bits equal to "11", pixel data 
is written to all buffers. The display is refreshed from the buffer specified by the 
beingjiisplayed pointer. After the display refreshes the last pixel in one frame refresh 
epoch and before it begins to refresh the first pixel in the next frame refresh epoch the 
display update process performs the operation of scting bcingjrcfrcshcd equal to 
justjfilled; 

[00716] The The Video Stream Packet contains a pair of Display Update Bits that specify the 

frame buffer where the pixel data shall be written. The Display Capability Packet has three 
additional bits that indicate which combinations of the Display Update Bits are supported in 
the client In many cases, computer-generated images need to be incrementally updated 
based on user input or derived from information received from a computer network. 
Display Update Bit combinations "00" and "11" support this mode of operation by causing 
the pixel data to be written to the frame buffer being displayed or to both frame buffers, 

[00717] When accommodating video images, FIG. 92 illustrates how video images arc 
displayed using a pair of frame buffers when video data is transmitted over the MDDI link 
with the Display Update Bits equal to "01''. After a media-frame boundary is detected on 
the MDDI link, the display refresh process will begin refreshing from the next frame buffer 
when the refresh process for the frame currently being refreshed is completed. 

'IniaKr 0,bam | ftarnefl, butB | [ j*P j ^H^ ^j^ | < g" 83 l MA | ftanc4, But B | farfAj 
Two Sulfas, display refresh much fester Item image transfer 

[00718] An important assumption related to PIG 92 is that the image is received from the 

host as a continuous stream of pixels that are transmitted in the same order that the client 
uses to read the pixels from the frame buffer to refresh the display (usually upper-left, 
reading, row by row, to the bottom-right comer of the screen. This is an important detail in 
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the cases where the Display Refresh and Image Transfer operations reference the same 
frame buffer. 

[00719] It is necessary for the display refresh frame rate to be greater than the image transfer 

frame rate to avoid displaying partial images. "FIG, 93 shows how image fragmentation can 
occur with a slow display refresh rate, that is the display refresh is slower than the image 
transfer. 

Tvm Mfers, display refresh siower tail imags transfer 

[00720] In an image that contains a combination of computer graphic images and moving 

video pictures the video pixel data might occupy a small portion of a media-frame. This 
could be significant in situations where the display refresh operation and the image transfer 
reference the same frame buffer. These situations are shown by a cross-hatched shading in 
FIG. 94, where the pixels read from the buffer to refresh the display might be the pixels 
written to the buffer two frames ago, or they may correspond to the frame immediately 
being written to the same frame buffer. 

Two Buffers, display refresh much fester than image transfer, small video wfnilow 
T ^g j WrwJ.i^fs^A'-j 1 ramea, bufferB | .frarreJ^erA [ f^^J. l«rffefS~| tr^J,butoi [ ■ jwrnsj, MorB :.j 

[00721] The use of three frame buffers in the client will resolve the problem of the small 
window of contention for access to a frame buffer as shown in FIG. 95, 





j rrarpsj, bwferC I b*mi buifer A I frr-mta % buffer B \ J'rarrejJ, btf fer.07 | 




Hspl^j fmo,^! f roD ,M:j !me,M|lml,)»A|mil,<«f 





[00722] However, there is still a problem if the display refresh rate is less than the media- 

frame rate over the MDDI link as. shown in FIG.96. 
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Tlree Buffers, dspi^rrBtesti^oKW than image transfer 



h A j tane2.bd!iarB J 1 Mferp J. <«f«M> 


BrffsrA J frames , t if e ^ c j* 3 ™ 7 ! 









[00723] The use of a single buffer for moving video images is somewhat problematic as 

shown FIG. 97. With the display refresh faster than the image transfer into the buffer, the 
image being refreshed sometimes will show the upper portion of the frame being written 
and the lower portion of the image will be the frame previously transferred. With the 
display refresh faster than the image transfer (the preferred mode of operation) there will be 
more frequent instances of frames showing a similar split image. 




Ore Buffer, display refresh mwsi tester Dan tmaea transfer 
Twnr'sl "~ j farm 4 [ fre-rsB j ' ! *'" 39 [ 

XVII. Delay Value Table 
[00724] The Packet Processing Delay Parameters Packet uses a table-lookup function to 

calculate the predicted delay to process certain commands in the client. Values in the. table 
increase in a logarithmic fashion to provide a very wide dynamic range of delay values. An 
exemplary table of delay values useful for implementing embodiments of the invention is 
found in Table XX below, with corresponding index values versus delay values. 
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Tabei XX (add whole new table) 



1 - 46ps 

2 - Sips 

3- 56ps 


37- 1.5ns 
38 - 1.6ns 
39- 1.8ns 
40 - 2.0ns 


74 - 51ns 

75 - 56iis___ 

76 - 62ns 

77 - 68ns 


111 - L8us 
112-2.0us 

113 - 2.2us 

114 - 2.4us 


148 - 62us 

149 - 68us 

150 - 75us 
151-~S3us 


186 - 2.4ms 

|g 7 . > 6ms 

188 - 2.9ms 


223 - 83ms 

224 - 91ms 




41 ■"2.2;is 


78 ■- 75ns 


115-2.6us 








5 '""'lips 






153 - lOOus 


190 - 3 5ms 


227 - 120ms 


6,7 75ps 


43 - 2.6ns 

44 - 2.9ns 


||"..||||- 




155 - 120ns 


191 - 3.8nis 

192 -4.2ms 


229 - 150ms 




45 - 3.2ns 


82 - 110ns 


119 - 3,Sus 


156- 130us 


193 -4.6ms 


"230 - MGim 


9-100ps 


46 - 3.5ns 


S3 - 120ns 


120 - 4.2ua 


157 - 150us 


194 - 5.1ms 


231 - ISOms 


10 - 11 Ops _ 

11 - 120ps 

12 ■■ 130ps 


47 - 3.8ns 
4S - 4.2ns 
49 -4,6ns 


84 - 130ns 


121 - 4.6us 


158 - 160us 


T96- 6.2ms " 
197 - 6.8ms 


'"233':''|20ms ™ 


....||..r..l|Sg5 


-||| 55^" "~" 


159- ISOus 

160- 200us 


234 - 240ms 


13 - ISOps 


50 -5.1ns 


8" - j gQns 


124 - 6,2us 


161 - 220us 


V>*- 7.5ms 


14 - 16Qps 

15 - ISOps 

Tr^if'pT" 


51 -5.6ns 


88 - 200ns 


125 - 6,8us 


162 - 240us 

163 - 260us 

164 290us 


199 -8.3ms 


'236 -290ms 


52 - 6.2ns 

"'ir-'ijnir"' 


89 - 220ns 

90 - 240ns 


126 - 7.5us 

127 -I.3us " 


200 -9.1ms 
201 - 10ms 


237 - 320ms 
23H - 350ms 


"T? : 22o s » " 


* ■■ 7 , 


91 -260ns 


128-9.1us 


165 - 320us 


202 - 1 1 i js 


T3"9-"38to7 


IS - 240ps 


55 - 8.3ns 


92-290n S 


I 29 ' )o ; 


166- 350us 


203 - 12ms 


240 -420m, 



19 - 260ps 






130- 11ns 


167- 3S0us 


2.04 - 13ms 


241 -460ms 


20 - 290ps 


57 - 10ns 


94 - 350ns 


131 - 12us 


168 - 420us 


205 - 15ms 


242 - 510ms 


ii - yj.V[k 


58- Una 


95 - 380ns 


132 - 13us 


169 -460us 


206 -16ms 


243 - 5.60ms 


22 - 350ps 


59 - 1 2ns 


96 -420ns 


133- 15us 


170-5l0us 


207 - ISros 


244 - 620ms 


23-3S0ps 


60 - 13ns 


97 -460ns 


134 - 16us 


171 - 560us 


208 - 20ms 


245 - 680ms 


24 - 420ps 


61 - 15ns 


98 -510ns 


135 - 18us 


172 - 620us 


209 - 22ms 


246 - 750m.s 


25 - 460ps 


62 - 16ns 


99 - 560ns 


136 - 20us 


173 - 680us 


210 - 24ms 


247 - 830ms 


26 51 Ops 


63 - 18ns 


100 - 620ns 


137 - 22us 


174 - 750us 


211 -26ms 


248 - 910ms 


27 - 560ps 


61 - 20ns 


101 - 680ns 


138-24us 


175 - 830us 


212 - 29ms 


249 


28 - 620ns. 


65 - 22ns 


102 -750ns 


139-26us 


176-910us 




250- U see 


29 - 6S0ps 


66 -24ns ' 


103 - 830ns 


140 -29us 


177 -1.0ms 


214 -35ms 




30 - 75Qps 


67 - 26ns 


104 - 910ns 


141 - 32us 


178 - 1.1ms 


215 - 38ms 








105 - l.Ous 




179- 1.2ms 








69 -32ns 


1 06 - Uus | 143 - 3Sus j 1 80 - 1. .3ms 






33- 1.0ns 


70 - 35ns 








34- 1.1ns 


71 - 38ns 








35 - 1.2ns 


72 - 42ns 


109"'- T.5ns 146 -Shis 183-T.Sms 


220 - 62ms 




36- 1.3ns 


73 - 46ns 


110 - 1.6 us I 147 - 56us | 184 - 2.0ms 


221 - 68ms 





[00725] The delay is computed by performing a table lookup using the specified parameter 

as an index into the table. This means a delay is equal to PacketProcessingTable(index). 
For example: if one of the parameters from the Delay Parameters List Item is an 8-bit value 
equal to 134, then the- delay is equal to PacketProcessi ngTabIe( 1 34) which is 16 usee. The 
value 255 indicates that the command completion time cannot be determined by calculation, 
and that the host must check the Graphics Busy Flags in the Display Request and Status 
Packet or MCCS VCP Control Parameter B7h. 
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[00726] In some cases this delay is multiplied by the height, width., or number of pixels in 

the destination image and added to other delays to compute the overall packet processing 
delay. 

X\ H Multiple Client Support 

[00727] The current protocol version does not appear to directly support multiple client 

devices. However, most packets contain a reserved Client ID field that can be used to 
address specific client devices in a system with multiple clients. Currently, for many 
applications this client ID or these client IDs are set to be zero. The sub-frame header 
packet also contains a field to indicate whether or not the host supports a multiple client 
system. Therefore, there is a manner in which multiple client devices would likely be 
connected and addressed in future applications of the MOD interface or protocol to aid 
system designers to plan for future compatibility with multiple client hosts and clients. 

[00728] In systems having multiple clients it is useful for clients to be connected to the host 
via a daisy-chain of clients, or using hubs, 

XV 01. Addendum 

[00729] In addition to the formats, structures, and contents discussed above for the various 
packets used to implement the architecture and protocol for embodiments of the invention, 
more detailed field contents or operations are presented here for some of the packet types. 
These are presented here to further clarify their respective use or operations to enable those 
skilled in the ait to more readily understand and make use of the invention for a variety of 
applications. Only a few of the fields not already discussed are discussed further here. In 
addition, these fields are presented with exemplary definitions and values in relation to the 
embodiments presented above. However, such values are- not to be taken as limitations of 
the invention, but represent one or more embodiments useful for implementing the interface 
and protocol, and not all embodiments need be practiced together or at the same time. 
Other values can be used in other embodiments to achieve the desired presentation of data 
or data rate transfer results, as will be understood by those skilled in the art. 



A. For Video Stream Packets 

[00730] In one embodiment, the Pixel Data Attributes field (2 byte) has a series of bit values 

that are interpreted as follows. Bits 1 and 0 select how the display pixel data is routed. For 
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bit values of 11' data is displayed to or for both eyes, for bit values 10", data is routed only 
to the left eye, and for bit values '01', data is routed only to the right eye, and for bit values 
of '00' the data is routed to an alternate display as may be specified by bits 8 through 11 
discussed below. 

[0073 1] Bit 2 indicates whether or not the Pixel Data is presented in an interlace format, with 

a value of '0' meaning the pixel data is in the standard progressive Format, and that the row 
number (pixel Y coordinate) is incremented by 1 when advancing from one row to the next 
When this bit has a value of T, the pixel data is in interlace format, and the row number is 
incremented by 2 when advancing from one row to the next. Bit 3 indicates that the Pixel 
Data is in alternate pixel format. This is similar to the standard interlace mode enabled by 
bit 2, but the interlacing is vertical instead of horizontal. When Bit 3 is '0' the Pixel Data is 
in the standard progressive format, and the column number (pixel X coordinate) is 
incremented by 1 as each successive pixel is received. When Bit 3 is 'V the Pixel Data is 
in alternate pixel format, and the column number is incremented by 2 as each pixel is 
received. 

[00732] Bit 4 indicates whether or not the Pixel data is related to a display or a camera, as 
where data is being transferred to or from an internal display for a wireless phone or similar 
device or even a portable computer, or such other devices as discussed above, or the data is 
being transferred to or from a camera built into or directly coupled to the device. When Bit 
4 is '0' the Pixel data is being transferred to or from a display frame buffer. When Bit 4 is 
T Pixel data is being transferred to or from a camera or video device of some type, such 
devices being well known in the ait. 

[00733] Bit 5 is used to indicate when the pixel data contains the next consecutive row of 

pixels in the display. This is considered the case when Bit 5 is set equal to T. When bit 5 
is set to T then the X Left Edge, Y Top Edge, X Right Edge, Y Bottom Edge, X Start, and 
Y Start parameters are not defined and are ignored by the client. The Frame Sync Packet 
defines the next row to be the top row of the image. 

[00734] Bits 7 and 6 are Display Update Bits that specify a frame buffer where the pixel data 

is to be written. There more specific effects are discussed elsewhere. For bit values of '01' 
Pixel data is written to the offline image buffer. For bit values of '00* Pixel data is written 
to the image buffer used to refresh the display. For bit values of '1 F Pixel data is written to 
all image buffers. The bit values or combination of '10' is treated, as an invalid value or 
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designation and Pixel data is ignored and not written to any of the image buffers. This 
value may have use for future applications of the interface. 

[00735] Bits 8 through 1 1 form a 4-bit unsigned integer that specifies an alternate display or 

display location where pixel data is to be routed. Bits 0 and 1 are equal to 00 in order for 
the display client to interpret bits 8 through 11 as an alternate display number. If bits 0 and 
1 are not equal to 00 then bits 8 through 11 are set to zero. 

[00736] Bits 12 through 15 are reserved for future use and are generally set as zero 

[00737] The 2-byte X Start and Y Start fields specify the absolute X and Y coordinates of 

the point (X Start, Y Start) for the first pixel in the Pixel Data field. The 2-byte X Left 
Edge and Y Top Edge fields specify the X coordinate of the left edge and Y coordinate of 
the top edge of the screen window filled by the Pixel Data field, while the X Right Edge 
and Y Bottom Edge fields specify the X coordinate of the right edge, and the Y coordinate 
of the bottom edge of the window being updated. 

[00738] The Pixel Count field (2 bytes) specifies the number of pixels in the Pixel Data field 
below, 

[00739] The Parameter CRC field (2 bytes) contains a CRC of all bytes from the Packet 

Length to the Pixel Count. If this CRC fails to check then the entire packet is discarded. 
[00740] The Pixel Data field Contains the raw video information that is to be displayed, and 

which is formatted in the manner described by the Video Data Format Descriptor field. The 

data is transmitted one "row" at a time as discussed elsewhere. 
[00741] The Pixel Data CRC field (2 bytes) contains a 16-bit CRC of only the Pixel Data, if 

a CRC verification of this value fails then the Pixel Data can still be used, but the CRC 

error count is incremented. 

B- Kor Audio Stream Packed 

[00742] In one embodiment, the Audio Channel ID field (1 byte) uses an 8 bit. unsigned 

integer value to identify a particular audio channel to which audio data is sent by the client 
device. The physical audio channels are specified in or mapped to physical channels by this 
field as values of 0, 1, 2, 3, 4, 5, 6, or 7 which indicate the left front, right front, left rear, 
right rear, front center, sub-woofer, surround left, and surround right channels, respectively. 
An audio channel ID value of 254 indicates that the single stream, of digital audio samples is 
sent to both the left front and right front channels. This simplifies communications for 
applications such as where a stereo headset is used for voice communication, productivity 
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enhancement apps are used on a PDA, or other applications where a simple User Interface 
generates warning tones. Values for the ID field ranging from 8 through 253, and 255 are 
currently reserved for use where new designs desire additional designations, as anticipated 
by those skilled in the art. 

.[00743] The Reserved 1 field (1 byte) is .generally reserved for future use, and has all bits in 

this field set to .zero. One function of this field is to cause all. subsequent 2 byte fields to 
align to a 16-bit word address and cause 4 -byte fields to align to a 32-bit word address. 

[00744] The Audio Sample Count field (2 bytes) specifies the number of audio samples in 

this packet. 

[00745] The Bits Per Sample and Packing field contains 1 byte that specifies the packing 
format of audio data. In one embodiment, the format generally employed is for Bits 4 
through 0 to define the number of bits per PCM audio sample. Bit. 5 then specifies whether 
or not the Digital Audio Data sa nt es are pi: I ed \s mentioned above, F IG. 12 illustrates 
the difference between packed and byte-aligned audio samples. A value of '0' for Bit 5 
indicates that each PCM audio sample in the Digital Audio Data field is byte-aligned with 
the interface byte boundary,, and a value of T indicates that each successive PCM- audio 
sample is packed up against the previous audio sample. This bit is effective only when the 
value defined in hits 4 through 0 (the number of bits per PCM audio sample) is. not a 
multiple of eight, Bits 7 through 6 are reserved for use where system designs desire 
additional designations and are generally set at a value of zero. 

[00746] The Audio Sample Rate field (1 byte) specifies the audio PCM sample rate. The 
format employed is for a value of 0 to indicate a rate of 8,000 samples per second (sps), a 
value of 1 indicates 16,000 sps., value of 2 for 24,000 sps, value of 3 for 32,000 sps, value 
of 4 for 40,000 sps, value of 5 for 48,000 sps, value of 6 for 11,025 sps, value of 7 for 
22,050 sps, and value of 8 for 44,100 sps, respectively, with values of 9 through 255 being 
reserved for future use, so they are currently set to zero. 

[00747] The Parameter CRC field <2 bytes) contains a 16-bit CRC of all bytes from the 
Packet Length to the Audio Sample Rate. If this CRC fails to check appropriately, then the 
entire packet is discarded. The Digital Audio Data field contains the raw audio samples to 
be played, and is usually in the form of a linear format as unsigned integers. The Audio 
Data CRC field (2 bytes) contain a 16-bit CRC of only the Audio Data. If this CRC fails to 
check then the Audio Data can still be used, but the CRC error count is incremented. 
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C. For User-Defined Stream Packets 

[00748] In one embodiment, the 2-byte Stream ED Number field is used to identify a 

particular user defined stream. The contents of the Stream Parameters and Stream Data 
fields, are typically defined by the MDDI equipment manufacturer. The 2-byte Stream 
Parameter CRC Field contains a 16-bit CRC of all bytes of the stream parameters starting 
from the Packet Length to the Audio Coding byte. If this CRC fails to cheek then the entire 
packet is discarded. Both the Stream Parameters and Stream Parameter CRC fields may be 
discarded if not needed by an end application of the MI)D interface, that is, they are 
considered optional. The 2-byte Stream Data CRC field contains; a CRC of only the Stream 
Data. If this CRC fails to check appropriately, then use of the Stream Data is optional, 
depending on the requirements of the application. Use of the stream data contingent on the 
CRC being good, generally requires that the stream data be buffered .until the CRC is 
confirmed as being good. The CRC error count is incremented if the CRC does not check. 



D. For Color Map Packets 

[00749] The 2-byte hClicnt ID field contains information or values that are reserved for a 
Ghent ID, as used previously. Since this field is generally reserved for future use, the 
current value is set to zero, by setting the bits to '0'. 

[00750] The 2-byte Color Map Item Count field uses values to specify the total number of 3- 
byte color map items that are contained in the Color Map Data field, or the color map table 
entiles that exist in the Color Map Data in this packet. In this embodiment, the number of 
bytes in the Color Map Data is 3 times the Color Map Item Count. The Color Map Item 
Count is set equal to zero to send no color map data. If the Color Map Size is zero then a 
Color Map Offset value is generally stil] sent but it is ignored by the display. The Color 
Map Offset field (4 bytes) specifies the offset of the Color Map Data fa this packet from the 
beginning of the color map table in the client device. 

[00751] A 2 byte Parameter CRC field contains a CRC of all bytes from the Packet Length 

to the Audio Coding byte. If this CRC fails to check then the entire packet is discarded. 

[00752] For the Color Map Data field, the width of each color map location is a specified by 
the Color Map Item Size field, where in one embodiment the first bar* specifies the 
magnitude of blue, the second part specifies the magnitude of green, and the third part 
specifies the magnitude of red. The Color Map Size field specifies the number of 3 -byte 
color map table items that exist in the Color Map Data field. If a single color map cannot fit 
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into one Video Data Format and Color Map Packet, then the entire color map may be 
specified by sending multiple packets with different Golor Map Data and Color Map 
Offsets in each packet. The number of bits of blue, green, and red in each color map data 
item shall be the same as specified in the Color Map RGB Width field of the Display 
Capability Packet, 

[00753] A 2-byte Color Map Data CRC field contains a CRC of only the Color Map Data, If 

this CRC fails to check then the Color Map Data can still be used but the CRC error count 
is incremented. 

[00754] Each color map data item is to be transmitted in the order; blue, green, red, with the 
least significant bit of each component transmitted first. The individual red, green, and blue 
components of each color map item shall be packed, but each color map item (the least 
significant bit of the blue component) should be byte-aligned. Error! Reference source 
not found. (New Z?7) shows an example of color map data items with 6 bits of blue, 8 bits 
of green, and 7 bits of red. For this example the Color Map Item Size in the Color Map 
Packet is equal to 21, and die Color Map RGB Width field of the Display Capability Packet 



equal to 0x0786. 

Color Bap Data Formatting 




ag«»5K 











E. For Reverse Link E ncapsulation Packets 

[00755] The Parameter CRC field (2 bytes) contains a 16-bit CRC of all bytes from the 

Packet Length to the Turn-Around Length. If this CRC fails to check then the entire packet 
is discarded. 

[00756] In one embodiment, the Reverse Link Flags field (1 byte) contains a set of flags to 
request information from the display. If a bit (for example, Bit 0) is set to one then the host 
requests the specified information from the display using the Display Capability Packet. If 
the bit is zero then the host does not need the information from the display. The remaining 
bits (here Bite 1 through 7) are reserved for future use and are set to zero. However, more 
bits can be used as desired to set flags for the reverse link. 

[00757] The Reverse Rate Divisor field (1 byte) specifies, the number of MDDI„Stb cycles 

that occur in relation to the reverse link data clock. The reverse link data clock is equal to 



WO 2005/018191 



PC171TS2004/026264 



145 

the forward link data clock, divided by two times the Reverse Rate Divisor, The reverse 
link data rate is related to the reverse link data clock and the Interface Type on the reverse 
link. For a Type I interface the reverse data rate equals the reverse link data clock, for Type 
II, Type HI, and Type IV interfaces the reverse data rates equal two times, four times, and 
eight times the reverse link data clock, respectively. 
[00758] The All Zerol field contains a group of bytes that is set equal to zero in value by 

setting the bits at a logic-zero level, and is used to ensure that all MDDIJData signals are in 
the zero state prior to disabling the line drivers during the first Guard Time period, to allow 
reflected logic-one levels to dissipate prior to disabling the Host's line drivers during the 
Turn-Around 1 field. In one embodiment, the length, of the All Zero 1 field is greater than 
or equal to the number of forward link byte transmission times in the round-trip delay of the 
cable. 

[00759] The Turn-Around 1 Length field (1 byte) specifies the total number of bytes that are 

allocated for Turn-Around 1, establishing the first turn-around period. The number of bytes 
specified by the -Turn-Around Length parameter are allocated to allow the MDDLPata line 
drivers in the Host to disable before the line drivers in the client are enabled. The host 
disable its MDDIJData line drivers during bit 0 of Turn- Around 1 and the client enables its 
outputs and drives MDDljDataO to a logic 0 during the last bit of Turn- Around 1. The 
MDPLStb signal behaves as though the Turn Around 1 period were all zeros. The 
recommended length of Turn- Around 1 is the number of bytes required for the MDDIJData 
drivers in a host to have the outputs disabled. This is based on the output disable time 
discussed above, the forward link data rate, and the forward link Interface Type selection 
being used. A more complete description of the setting of Turn- Around 1 is given above. 

[00760] The All Zero 2 field contains a group of bytes that is set equal to zero in value by 

setting the bits at a logic-zero level, and is used to ensure that all MDDIJData signals are- in 
the aero state to allow reflected logic-one levels to dissipate prior to disabling the host' s line 
drivers during the Turn-Around 1 field, In one embodiment, the length of the All Zero 2 
field is greater than or equal to the number of forward link byte transmission times in the 
round-trip delay of the cable. 

[00761] The Turn-Around 2 Length field (1 byte) specifies the total number of bytes that are 

allocated for Turn-Around 2, for establishing a second turn-around period. The number of 
bytes is specified by the Turn-Around .Length parameter are allocated to allow the 
MDDIJData line drivers in the client to disable before the line drivers in the host are 
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enabled. The client disables its MDDIJData line drivers during bit 0 of Turn-Around 2 and 
the host enables its outputs and drives MDDIJDataO to a logic 0 during the last bit of Turn- 
Around 2, The MDDT_Sfb signal behaves as though the MDDIJMaO were at a logic-zero 
level during the entire Turn Around 2 period. The recommended length of Turn-Around 2 
is- the number of bytes- required for the MDDI„T>ata drivers in the Display to disable their 
outputs plus the round-trip delay. A description of the setting of Turn- Around 2 is given 
above. 

[00762] The Reverse Data Packets field contains a series of data packets being transferred 

from: the client to a host. As stated earlier, Filler packets are sent to fill the remaining space 
that is not used by other packet types. 

[00763] The Driver Re-enable field uses 1 byte that is equal to logic-zero to ensure that all 
MDDIJData signals arc re-enabled prior to the Packet Length Field of the. next packet. 

F. For Display Capability Packets 

[00764]; In one embodiment, the Protocol Version field uses 2 bytes to specify a protocol 
version used by the client The initial version is set equal to zero, while the Minimum 
Protocol Version field uses 2 bytes to specify the minimum protocol version that the client 
can employ or interpret. The Display Data Rate Capability field (2 bytes) specifies the 
maximum data rate the display can receive on the forward link of the interface, and is 
specified in the form of megabits per second (Mbps). The Interface Type Capability field 
(1 byte) specifies the interface types that are supported on the forward and reverse links. 
This is currently indicated by selecting Bit 0, Bit 1, or Bit 2 to select either a TypeTL Type- 
Ill or Typc-IV mode on the forward link, respectively, and Bit 3, Bit 4, or Bit 5 to select 
either a Type-II. Type-Ill, or Type-lV mode on the reverse link, respectively; with Bits 6 
and 7 being reserved and set to zero. The Bitmap Width and Height fields (2 bytes) specify 
the width and height of the bitmap in pixels. 

[00765] The Monochrome Capability field (1 byte) is used to specify the number of bits of 
resolution that can be displayed in a monochrome format. If a display cannot use a 
monochrome format, then this value is set at zero. Bits 7 through 4 are reserved for future 
use and are, thus, set as zero. Bits 3 through 0 define the maximum number of bits of 
grayscale that can exist for each pixel. These four bits make it possible to specify values of 
1 to 15 for each pixel. If the value is zero then monochrome format is not supported by the 
display. 
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[00766] The Color Map Capability field (3 bytes) specifies the maximum number of table 
items that exist in the color map table in the display. If the display cannot use the color map 
format then this value is zero. 

[00767] The RGB Capability field (2 bytes) specifies the number of bits of resolution that 
can be displayed in RGB format. If the display cannot use the RGB format then this value 
is equal to zero. The RGB Capability word is composed of three separate unsigned values 
where; Bits 3 through 0 define the maximum number of bits of blue, Bits 7 through 4 define 
the maximum number of bits of green, and Bits 11 through S define the maximum number 
of bits of red in each pixel. Currently, Bits 15 through 12 are reserved for future use and 
are generally set to zero. 

[00768] The Y Cr Cb Capability field (2 bytes) specifies the number of bits of resolution that 
can be displayed in Y Cr Cb format. If the display cannot use the Y Cr Cb format then this 
value is set equal to zero. The Y Cr Cb Capability word is composed of three separate 
unsigned values where: Bits 3 through 0 define the maximum number of bits in the Gb 
sample, Bits 7 through 4 define the maximum number of bits in the Cr sample, Bits 11 
through 8 define the maximum number of bits in the Y sample, and Bits 15 through 12 are 
currently reserved for future use and are set to zero. 

[00769] The Display Feature Capability Indicators field uses 4 bytes that contain a set of 
flags feat indicate specific features in the display that are supported. A bit set to one 
indicates the capability is supported, and a bit set to zero indicates the capability is not 
supported. The value for Bit 0 indicates whether or not Bitmap Block Transfer Packet 
(packet type 71) is supported. The value for Bits 1, 2, and 3 indicate whether or not Bitmap 
Area Fill Packet (packet type 72), Bitmap Pattern Fill Packet (packet type 73). or 
Communication Link Data Channel Packet- (packet type 74), respectively, are supported. 
The value for Bit 4 indicates whether or not the display has the capability to make one color 
transparent,- while values for bits Bit 5 and 6 indicate if the display can accept video data or 
audio data in packed format, respectively, and the value for Bit 7 indicates if the display can 
send a reverse-link video stream from a camera. The value for Bits 11 and 12 indicate 
when the client is communicating either with a pointing device and can send and receive 
Pointing Device Data Packets, or with a keyboard and can send and receive Keyboard Data 
Packets, respectively. Bits 13 through 31 are currently reserved for future use or alternative 
designations useful for system designers and are generally set equal to zero. 
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[00770] The Display Video Frame Rate Capability field (1 byte) specifies the maximum 

video frame update capability of the display in frames per second, A host may choose to 
update the image at a slower rate than the value specified in this field. 

[00171] The Audio Buffer Depth field (2 bytes) specifies the depth of the elastic buffer in a 

Display which is dedicated to each audio stream. 

[00772J The Audio Channel Capability field (2 bytes) contains a group of flags that indicate 

which audio channels are supported by the display (client). A bit set to one indicates the 
channel is supported, and a bit set to zero indicates that channel is not. supported. The Bit 
positions are assigned to the different channels, for example Bit positions 0, 1, 2, 3, 4, 5, 6, 
and 7 indicate the left front, right front, left rear, right rear, front center, sub-woofer, 
surround left, and surround right channels, respectively. Bits 8 through 15 are currently 
reserved for future use, and are generally set to zero. 

[00773] A 2-bytc Audio Sample Rate Capability field, for the forward link, contains a set of 
flags to indicate the audio sample rate capability of the client device. Bit positions are 
assigned to the different rates accordingly, such as Bite 0, 1, 2, 3. 4, 5, 6, 7, and 8 being 
assigned to 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and 44,100 
samples per second (SPS), respectively, with Bits 9 through 15 being reserved for future or 
alternative rate uses, as desired, so they are currently set to '0'. Setting a bit value for one of 
these bits to 1' indicates that that particular sample rate is supported, and setting the bit to 
'0* indicates that that sample rate is not supported. 

[00774] The Minimum Sub-frame Rate field (2: bytes) specifies the minimum sub-frame rate 

in frames per second. The minimum sub-frame rate keeps the display status update rate- 
sufficient to read certain sensors or pointing devices in the display. 

[00775] A 2-byte Mic Sample Rate Capability field, for the reverse link, mat contains a set 

of flags that indicate the audio sample rate capability of a microphone in the client device. 
For purposes of the MDDI, a client device microphone is configured to minimally support 
at least an 8,000 sample per second rate. Bit positions for this field are assigned to the 
different rates with bit positions 0, 1, 2, 3, 4, 5, 6, 7, and 8, for example, being used to 
represent 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, and 44,100 
samples per second (SPS), respectively, with Bits 9 through 15 being reserved for future or 
alternative rate uses, as desired, so they are currently set to '0'. Setting a bit value for one of 
these bits to 1 indicates that that particular .sample rate is supported, and setting the bit to 
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*0' indicates that that sample rate is not supported. If no microphone is connected then each 
of the Mic Sample Rate Capability bits are set equal to zero. 
[00776] The Content Protection Type field (2 bytes) contains a set of flags that indicate the 

type of digital content protection that is supported by the Display. Currently, bit position 0 
is used to indicate when DTCP is supported and bit position 1 is used to indicate when 
HDCP is supported, with bit positions 2 through 15 being reserved for use with other 
protection schemes as desired or available, so they are currently set to zero. 

G. For Display Request and Status Packets 

[00777] The Reverse Link Request field (3 byte) specifies the number of bytes the display 

needs in the reverse link in the next sub-trams to send information to the host. 

100778] The CRC Error Count field (I byte) indicates how many CRC errors have occurred 
since the beginning of the media-frame. The CRC count is reset when a sub-frame header 
packet with a Sub-frame Count of zero is sent. If the actual number of CRC errors exceeds 
255 then this value generally saturates at 255. 

[00779] The Capability Change field uses 1 byte to indicate a change in the capability of the 

display. This could occur if a user connects a peripheral device such as a microphone,, 
keyboard, or display, or for some other reason. When Bits[7:0] are equal to 0, then the 
capability has not changed since the last Display Capability Packet was sent. However, 
when Bits[7:0] are equal to 1 to 253, the capability has changed. The Display Capability 
Packet is examined to determine the new display characteristics. 

H. For Bit Block Transfer Packets 

[007SO] The Window Upper Left Coordinate X Value and Y Value fields use 2 bytes each to 

specify the X and Y value of the coordinates of the upper left comer of the window to be 
moved. The Window Width and Height fields use 2 bytes each to specify the width and 
height of the window to be moved. The Window X Movement and Y Movement fields use 
2 bytes each to specify the number of pixels that the window is to be moved horizontally 
and vertically, respectively. Typically, these coordinates are configured such that positive 
values for X cause the window to be moved to the right,, and negative values cause 
movement to the left, while positive values for Y cause the window to be moved down, and 
negative values cause upward movement. 
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I. For Bitmap Area Fill Packets 

[00781] Window Upper Left Coordinate X Value and Y Value fields use 2 bytes each to 

specify the X and Y value of the coordinates of the upper left corner of the window to be 
filled. The Window Width and Height fields (2 bytes each) specify the width and height of 
the window to be filled, The Video Data Format Descriptor field (2 bytes) specifies the 
format of the Pixel Area Fill Value. The format is the same as the same field in the Video 
Stream Packet. The Pixel Area Fill Value field (4 bytes) contains the pixel value to be 
filled into the window specified by the fields discussed above. The format of this pixel is 
specified in the Video Data Format Descriptor field. 



J. For Bitmap Pattern Fill Packets 

[00782] . Window Upper Left Coordinate X Value and Y Value fields use 2 bytes each to 
specify the X and Y value of the coordinates of the upper left corner of the window to be 
filled. The Window Width and Height fields (2 bytes each) specify the width and height of 
the window to be filled. The Pattern Width and Pattern Height fields (2 bytes each) specify 
the width and height, respectively, of the fill pattern. The 2-byte Video Data Format 
Descriptor field specifies the format of the Pixel Area Fill Value. FIG. 1 1 illustrates how 
the Video Data Format Descriptor is coded. The format is the same as the same field in the 
Video S tream Packet. 

[00783] The Parameter CRC field (2 bytes) contains a CRC of all bytes from the Packet 

Length to the Video Format Descriptor. If this CRC fails to check then the entire packet is 
discarded. The Pattern Pixel Data field contains raw video information that specifies the fill 
pattern in the format specified by the Video Data Format Descriptor. Data is packed into 
bytes, and the first pixel of each row must be byte-aligned. The fill pattern data is 
transmitted a row at a time. The Pattern Pixel Data CRC field (2 bytes) contains a CRC of 
only the Pattern Pixel Data. If this CRC fails to check then the Pattern Pixel Data can still 
be used but the CRC error count is incremented. 



K. Communication Link Data Channel Packets 

[00784] The Parameter CRC field (2 bytes) contain a 16-bit CRC of all bytes from the 

Packet Length to the Packet Type. If this CRC fails to check then the entire packet is 
discarded. 
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[007S51 The Communication Link Data field contains the raw data from the communication 

channel, This data is simply passed on to the computing device in the display. 

[007S6] The Communication link Data CRC field (2 bytes) contains a 16-bit CRC of only 

the Communication Link Data. If this CRC fails to check then the Communication Link 
Data is still used or useful, but the CRC error count is incremented. 

L. For Interface Type Handoff Request Packets 
[00787] The Interface Type field (1 byte) specifies the new interface type to use. The value 

in this field specifies the interface type in the following manner. If the value in Bit 7 is 
equal to '0' the Type handoff request is for the forward link, if it is equal to 1', then the 
Type handoff request is for the reverse link. Bits 6 through 3 are, reserved for future use, 
and are generally set to zero. Bits 2 through 0 are used to define the interface Type to be 
used, with a value of 1 meaning a handoff to Type-I mode, value of 2 a handoff to Type-E 
mode, a value of 3 a handoff to Type-in mode, and a value of 4 a handoff to Type-IV 
mode. The values of '0' and 5 through 7 are reserved for future designation of alternative 
modes or combinations of modes. 

M. For Interface Type Acknowledge Packets 

[00788] The Interface Type field (1 byte) has a value that confirms the new interface type to 
use. The value in this field specifies the interface type in the following manner. If Bit 7 is 
equal to '0' the Type handoff request is for the forward link, alternatively, if it is equal to T 
the Type handoff request is for the reverse link. Bit positions 6 through 3 are currently 
reserved for use in designating other handoff types, as desired, and are generally set to zero. 
However, bit positions 2 through 0 are used define the interface Type to be used with a 
value of '0' indicating a negative acknowledge, or that die requested handoff cannot be 
performed, values of T, '2 ! , '3', and '4' indicating handoff to Type-I, Type-II, Type-Ill, and 
Type-IV modes, respectively. Values of 5 through 7 are reserved for use with alternative 
designations of modes, as desired. 



N. For Perform Type Handoff Packets 

[00789] The 1-byte Interface Type field indicates the new interface type to use. The value 

present in this field specifies the interface type by first using the value of Bit 7 to determine 
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whether or not the Type handoff is for" the forward or reverse links. A value of '0' indicates 
the Type handoff request is for the forward link, and a value of 1' the reverse- link. Bits 6 
through 3 are reserved for future use, and as such are generally set to a value of zero. 
However, Bits 2- through 0 are used to define the interface Type to be used, with the values 
1, 2, 3, and 4 specifying the use of handoff to Type- 1, Type-II, Type-Ill, and Type-IV 
modes, respectively. The use of values 0 and 5 through 7 for these bits is reserved for 
future use. 

O. For Forward Audio Channel. Enable Packets 
[00790] The Audio Channel Enable Mask field (1 byte) contains a group of flags that 
indicate which audio channels are to be enabled in a client. A bit set to one enables the 
corresponding channel, and a bit set to zero disables the corresponding channel Bits Q 
through 5 designate channels 0 through 5 which address left front, right front, left rear, right 
reai-, front center, and sub-woofer channels, respectively. Bits 6 and 7 are reserved for 
future use, and in the mean time arc generally set equal to zero. 

P. For Reverse Audio Sample Rale Packets 

100791] the Audio Sample Rate field(l byte) specifies the digital audio sample rate. The 
values for this field are assigned to the different rates with values of 0, 1, 2, 3, 4, 5, 6, 7, and 
8 being used to designate 8,000, 16,000, 24,000, 32,000, 40,000, 48,000, 11,025, 22,050, 
and 44,100 samples per second (SPS), respectively, with values of 9 through 254 being 
reserved for use with alternative rates, as desired, so they are currently set to '0'. A value of 

[00792] The Sample Format field (1 byte) specifies the format of the digital audio samples. 

When Bits[l:0] are equal to '0', the digital audio samples are in linear format, when they are 
equal to 1 , the digital audio samples are in ji-Law format, and when they are equal to 2, the 
digital audio samples are in A-Law format. Bits[7:2] are reserved for alternate use in 
designating audio formats, as desired, and are generally set. equal to zero, 

Q. For The Digital Content Protection Overhead Packets 
[00793} The Content Protection Type field (1 byte) specifies the digital content protection 
method that is used. A value of '0' indicates Digital Transmission Content Protection 
(DTCP) while a value of 1 indicates High-bandwidth Digital Content Protection System 
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(HDCP). The value range of 2 through 255 is not currenlly specified but is reserved lor use 
with alternative protection schemes as desired. The Content Protection Overhead Messages 
field is a variable length field containing content protection messages sent between the host 
and client. 

R. For The Transparent Color Enable Packets 

[00794] The Transparent Color Enable field (i byte) specifies when transparent color mode 

is enabled or disabled. If Bit 0 is equal to 0 then transparent color mode is disabled, if it is 
equal to 1 then transparent color mode is enabled and the transparent color is specified by 
the following two parameters. Bits 1 through 7 of this byte are reserved lor future use and 
are typically set equal to zero. 

[00795] The Video Data Format Descriptor field (2 bytes) specifies the format of the Pixel 
Area Fill Value, FIG. 11 illustrates how the Video Data Format Descriptor is coded. The 
format is generally the same as the same field in the Video Stream Packet. 

[00796] The Pixel Area Fill Value field uses 4 bytes allocated for the pixel value to be filled 

into the window specified above. The format of this pixel is specified in the Video Data 
Format Descriptor field. 

S. ■ For The Round Trip Delay Measurement Packets 
[00797] In one embodiment, the Parameter CRC field (2 bytes) contains a 16-bit CRC of all 
bytes from the Packet Length to the Packet Type. If this CRC fails to check then the entire 
packet is discarded. 

[00798] The All Zero field (1 byte) contains zeroes to ensure that all MDDIJData signals are 

in the zero state prior to disabling the line drivers during the first Guard Time period. 

[00799] The Guard Time 1 field (8 bytes) is used to allow the MDDI_Data line drivers in the 

host to disable before the line drivers in the client (display) are enabled. The host disables 
its MDDI_Data line drivers during bit 0 of Guard Time 1 and the Display enables its line 
drivers immediately after the last bit of Guard Time 1. 

[00800] The Measurement Period field is a 512 byte window used to allow the Display to 

respond with a Oxff, Oxff, 0x0 at half the data rate used on the forward link. This rate 
corresponds to a Reverse link Rate Divisor of 1. The Display returns this response 
immediately at the beginning- of the Measurement Period. This .response will be received at 
a host at precisely the round trip delay of the link after the beginning of the first bit of the 
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Measurement Period at the host. The MDDI JData line drivers in the Display are disabled 
immediately before and immediately after the Oxff, Oxff, 0x00 response from the Display. 

[00801] The value in the Guard Time 2 field (8 bytes) allows Client MDDIJData line drivers 
to disable before line drivers in the Host are enabled Guard Time 2 is always present but is 
only required when the round trip delay is at the maximum amount that can be measured in 
the Measurement Period. The Client disables its line drivers during bit 0 of Guard Time 2 
and the Host enables its line drivers immediately after the last bit of Guard Time 2. 

[00802] The Driver Re-enable field (1 byte) is set equal to zero, to ensure that all 

MDDIJData signals are re-enabled prior to the Packet Length Field of the next packet. 

T. For The Forward Link Skew Calibration Packets 

[00803] In one embodiment, the Parameter CRC field (2 bytes) contains a 16-bit CRC of all 
bytes from the Packet Length to the Packet Type. If this CRC fails to check then the entire 
packet is di scarded. 

[00804] The Calibration Data Sequence field contains a 512 byte data sequence that causes 
the MPDIJData signals to toggle at every data period. During the processing of the 
Calibration Data Sequence, the MDDI host controller sets all MDDIJData signals equal to 
the strobe signal. The display clock recovery circuit should use only MDDI.Stb rather than 
MDDI„Stb Xor MDDIJDataO to recover the data clock while the Calibration Data 
Sequence field is being received by the client Display. Depending on the exact phase of the 
MDDI.Stb signal at the beginning of the Calibration Data Sequence field, the Calibration 
Data Sequence will generally be one of the following based on the interface Type being 
used when this packet is sent: 

Type I - Oxaa, Oxaa ... or 0x55, 0x55... 
Type II - 0xcc ; Gxcc ... or 0x33, 0x33 . . . 
Type HI - OxfO, OxfO ... or OxOf , OxOf . . . 
Type J.Y - Oxff, 0x00, Oxff, 0x00 . . . or 0x00, Oxff, 0x00, Oxff . . > 

[00805] An example of the possible MDDI JData and MDDIJStb waveforms for both the 
Type-I and Type-II Interfaces are shown in FIGS. 62A and 62B, respectively. 
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XVH. Conclusion 

[00806] While various embodiments of the present invention have been described above, it 
should be understood -that they have been presented by way of example only, and not 
limitation. Thus, the breadth and scope of the present invention should not be limited by 
any of the above-described exemplary embodiments, but should be defined only in 
accordance with the following claims and their equivalents. 
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CLAIMS 

What is claimed is: 

1. A digital data interface for transferring digital presentation data at a high rate 
between a host device and a client device over a communication path comprising: 

a plurality of packet structures linked together to form a communication protocol for 
communicating a pre -selected set of digital control and presentation data between a host 
and a client over said communication path; and 

at least one link controller residing in said host device coupled to said client through 
said communications path, being configured to generate, transmit and receive packets 
forming said communications protocol, and to form digital presentation data into one or 
more types of data packets. 

2. The interface of Claim 1 further comprising said packets grouped together within 
media frames that are communicated between said host and client having a pre-defined 
fixed length with a pre-determined number of said packets have differing and variable 
lengths. 

3. The interface of Claim 1 further comprising a Sub-frame Header Packet positioned 
at the beginning of transfers of packets from said host. 

4. The interface of Claim 1 wherein said link controller is a host link controller and 
further comprising at least one client Jink controller residing in said client device coupled to 
said host through said communications path, being configured to generate, transmit, and 
receive packets forming said communications protocol, and to form digital presentation data 
into one or more types of data packets. 

5. The interface of Claim 1 further comprising one or more Video Stream Packets for 
video type data, and Audio Stream Packets for audio type data for transferring, data from 
said host to said client over a forward link for presentation to a client user. 
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6. The interface of Claim 2 further comprising; 

a plurality of transfer modes, each allowing the transfer of different maximum 
numbers of bits of data in parallel over a given time period, with each mode selectable by 
negotiation between said host and client link drivers; and 

wherein said transfer modes are dynamically adjustable between said modes during 
transfer of data. 

7. The interface of Claim 1 further comprising a plurality of packets usable to transfer 
video information chosen from the group of Color Map, Bit Block Transfer, Bitmap Area 
Fill, Bitmap Pattern Fill, and Transparent Color Enable type packets. 

8. The interface of Claim 1 further comprising Filler type packets generated by said 
host to occupy periods of forward link transmission that do not have data. 

9. The interface of Claim 1 further comprising User-Defined Stream type packets for 
transferring: interface-user defined data. 

10. The interface of Claim 1 further comprising a Link Shutdown type packet for 
transmission by said host to said client to terminate the transfer of data in either direction 
over said communication path. 

11. The interface of Claim 1 further comprising means for said client to wake up said 
host from a hibernation state. 

12. A method of transferring digital data at a high rate between a host device and a 
client device over a communication path for presentation to a user, comprising: 

generating one or more of a plurality of pre-defined packet structures and linking 
them together to form a pre-defined communication protocol; 

communicating a pre-selected set of digital, control and presentation data between 
said host and said client devices over said corrrinunication path using said communication 
protocol; 
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coupling at least one host link controller residing in said host device to said client 
device through said communications path, the host link controller being configured to 
generate, transmit, and receive packets forming said communications protocol, and to form 
digital presentation data into one or more types of data packets; and 

transferring data in the form of packets over said communications path using said 
link controllers. 

13. The method of Claim 12 further comprising grouping said packets together within 
media frames for communication between said host and client, the media frames having a 
pre-defined fixed length with a pre-dctermined number of said packets have differing and 
variable lengths, 

14. The method of Claim 12 further comprising commencing transfer of packets from 
said host with a Sub-frame Header type packet. 

15. The method of Claim 12 further comprising transferring information between said 
host and client bi-directionally over said communications link. 

16. The method of Claim 12 further comprising at least one client link controller 
residing in said client device coupled to said host device through said communications path, 
being configured to generate, transmit, and receive packets forming said communications 
protocol, and to form digital presentation data into one or more types of data packets. 

17. The method of Claim 16 wherein said host link controller comprises one or more 
differential line drivers; and said client link controller comprises one or more differential 
line receivers coupled to said communication path. 

IS, The method of Claim 12 further comprising requesting display capabilities 
information from the client by a host link controller so as to determine what type of data 
and data rates said client is capable of accommodating through said interface. 

19, The method of Claim 12 further comprising, operating a 1 JSB data interface by each 
of said link controllers as a part of said communication path. 
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20. The method of Claim 12 wherein said packets each comprise a packet- length field, 
one or more packet data fields, and a cyclic redundancy check field. 

21 . The method of Claim 1 3 further comprising: 

negotiating between said host and client link drivers the use of one of a plurality of 
transfer modes in each direction, each allowing the transfer of different maximum numbers 
of bits of data in parallel over a given time period', and 

dynamically adjusting between said transfer modes during transfer of data. 

22. The method of Claim 12 further comprising using one or more of a plurality of 
packets to transfer video information chosen from the group of Color Map, Bit Block 
Transfer, Bitmap Area Fill. Bitmap Pattern Fill, and Transparent Color Enable type packets. 

23. The method of Claim 12 further comprising generating Filler type packets by said 
host to occupy periods of forward link transmission that do not have data. 

24. The method of Claim 12 further comprising terminating the transfer of data in either 
direction over said communication path using a Link Shutdown type packet for 
transmission by said host to said client. 

25. The method of Claim 12 further comprising waking up said host from a hibernation 
state by communication with said client. 

26. Apparatus for transferring digital data at a high rate between a host device and a 
client device over a communication path for presentation to a user, comprising: 

at least one host link controller disposed in said host device for generating one or 
more of a plurality of pre-defined packet structures and linking them together to form a pre- 
defined communication protocol, and for communicating a pre-selected set of digital 
control and presentation data between said host and said client devices over said 
communication path using said communication protocol: 

at least one client controller disposed in said client device and coupled to said host 
link controller through said communications path; and 
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each link controller being configured to generate, transmit, and receive packets 
forming said communications protocol, and to form digital presentation data into one or 
more types of data packets. 

27. The apparatus of Claim 26 wherein said host controller comprises a state machine. 

28. The apparatus of Claim 26 wherein said host controller comprises a general purpose 
signal processor. 

29. The apparatus of Claim 26 further comprising a Sub-frame Header type packet at 
the commencing of transfer of packets from said host. 

30. The apparatus of Claim 26 wherein said link controllers are configured to transfer 
information between said host and client devices bi-directionally over said communications 
link. 

31. The apparatus of Claim 30 wherein said host controller comprises one or more 
differential line drivers; and said client receiver comprises one or more differential line 
receivers coupled to said communication path. 

32. The apparatus of Claim 26 further comprising Video Stream type packets for video 
type data, and Audio Stream type packets for audio type when transferring data from said 
host to said client for presentation to a client user. 

33. The apparatus of Claim 26 further comprising one or more Reverse Link 
Encapsulation type packets for transferring data from said client to said host. 

34. The apparatus of Claim. 33 further comprising at least one Display Capability type 
packet for communicating display or presentation capabilities from a client link controller 
to said host-link controller. 

35. The apparatus of Claim 26 wherein said packets each comprise a packet length field, 
one or more packet data fields, and a cyclic redundancy check field. 



WO 2005/018191 



PC17US2004/026264 



161 



36. The apparatus of Claim 26 wherein said host and client link controllers are 
configured to use of one of a plurality of transfer modes- in each direction, each allowing the 
transfer of different maximum numbers of bits of data- in parallel over a given time period; 
and being capable of being dynamically adjusting between said transfer modes during 
transfer of data. 



37. The apparatus of Claim. 2.6 further comprising one or more of a plurality of packets 
for transferring video information chosen from the group of Color Map, Bit Block Transfer, 
Bitmap Area Fill, Bitmap Pattern Pill, and Transparent Color Enable type packets. 

38. The apparatus of Claim 26 further comprising Filler type packets for transfer by said 
host to occupy periods of forward link transmission that do not have data. 

39. The apparatus of Claim 26 wherein said host controller is configured to transmit a 
Link Shutdown type packet to said client means for terminating the transfer of data in either 
direction over said communication path. 

40. For use in an electronic system for transferring digital data at a high rate between a 
host device and a client device over a communication path for presentation to a user, a 
computer program product comprising: 

a computer usable medium having computer readable program code means 
embodied in said medium for causing an application program to execute on the computer 
system, said computer readable program code means comprising: 

a computer readable first program code means for causing the computer system to 
generate one or more of a plurality of pre-defined packet structures and .link them together 
to foim a pre-defined communication protocol; 

a computer readable second program code means for causing the computer system 
to communicate a pre-selected set of digital control and presentation data between said host 
and said client devices over said communication path using said communication protocol; 

a computer readable third program code means for causing the computer system to 
couple at least one host link controller disposed in said host device to at least one client, 
controller disposed in said client device through said communications path, the link 
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controllers being configured to. generate, transmit, and receive packets forming said 
communications protocol, and to form digital presentation data into one or more types of 
data packets; and 

a computer readable fourth program code means for causing the computer system to 
transfer data in the form of packets over said communications path using said link 
controllers. 

41. Apparatus for transferring digital data at a high rate between a host device and a 
client device over a communication path for presentation to a user, comprising: 

means for generating one or more of a plurality of pre-defined packet structures and 
linking them together to form a pre-defined communication protocol; 

means for communicating a pre-selected set of digital control and presentation data 
between S^d host and said client devices over said communication path using said 
communication protocol; 

means for coupling at least two link controllers together through said 
communications path, one in each of said host and client and each being configured to 
generate, transmit, and receive packets forming said communications protocol, and to form 
digital presentation data into one or more types of data packets; and 

means for transferring data hi the form of packets over said communications path 
using said link controllers. 

42. The apparatus of Claim 41 further comprising means for commencing transfer of 
packets from said host with a Sub-frame Header type packet. 

43. The apparatus of Claim 41 farther comprising means for transferring information 
between said host and client bi-directionally over said communications link. 

44. The apparatus of Claim 41. further comprising means for requesting display 
capabilities information from the client by a host Ink controller so as to determine what 
type of data and data rates said client is capable of accommodating through said interface. 
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45. The apparatus of Claim 44 foirther comprising means for comniunicating display or 
presentation capabilities from a client link controller to said host link controller using at 
least one Display Capability type packet. 

46. The apparatus of Claim 42 further comprising: 

means for negotiating between said host and client link drivers The use of one of a 
plurality of transfer modes in each direction, each allowing the transfer of different 
maximum numbers of bits of data in parallel over a given time period; and 

means for dynamically adjusting between said transfer modes during transfer of 

data. 

47. Hie apparatus of Claim 41 further comprising means for using one or more of a 
plurality of packets to transfer video information chosen from the group of Color Map, Bit 
Block Transfer, Bitmap Area Fill, Bitmap Pattern Fill, and Transparent Color Enable type 
packets, 

48. A processor for use in an electronic, system for transferring digital data at a high rate 
between a host device and a client device over a communication path, the processor 
configured to generate one or more of a plurality of pre-defined packet structures and link 
them together to form a pre-defined communication protocol; to form digital presentation 
data into one or more types of data packets: communicate a pre-selecled set of digital 
control and presentation data between said host and said client devices over said 
communication path using said communication protocol; and transfer data in the form of 
packets over said communications path. 

49. A state machine for use in obtaining synchronization in an electronic system 
transferring digital data at a high rate between a host device and a client device over a 
communication path, the state machine configured to have at least one Async Frames State 
synchronization state, at least two Acquiring Sync States synchronization states, and at least 
three In-Syiic States synchronization states. 

50. A state machine for use in obtaining synchronization in an electronic system 
i ferring digital data at a high, rate between a. host device and a client device over a 
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communication path, the state machine 'configured to have at least one Acquiring Sync 
States synchronization states, and at least two In-Sync States synchronization states. 

51 The state machine of Claim 50, wherein one condition for shifting between an 
Acquiring Sync State and a first In-Sync State is detecting the presence of a synchronisation 
pattern in the communication Jink. 

52. The state machine .of Claim 51. wherein a second condition for shifting between an 
Acquiring Sync State and a first In-Sync State is detecting the presence of a sub-frame 
header packet and good CRC value at a frame boundary. 

53. The state machine of Claim 50, wherein one condition for shifting between a first 
In-Sync State and an Acquiring Sync State is detecting the presence of no synchronization 
pattern or a bad CRC value at a sub-frame boundary'. 

54. The state machine of Claim 50, wherein one condition for shifting between a first 
In-Sync State and a second In-Sync State is detecting the presence of no synchronization 
pattern or a bad CRC value at a sub-frame boundary. 

55. The state machine of Claim 50, wherein one condition for shifting between an 
Acquiring Sync State and a first In-Sync State is detecting the presence of a synchronization 
pattern, in the communication link is detecting the presence of a good packet CRC value. 

56. The state machine of Claim 50, wherein a condition for shifting between a first In- 
Sync State and an Acquiring Sync State is detecting the presence of a bad CRC value in a 

packet. 

57. A state machine for use in. obtaining synchronization in an electronic system 
transferring digital data at a high rate between a host device and a client device over a 
communication path, the state machine configured to have at least one Acquiring Sync 
States synchronization states, and at least two In-Sync States synchronization states, 
wherein; a condition for shifting directly between a first In-Sync State and an Acquiring 
Sync State is detecting the presence of a bad CRC value in any of a series of packets. 
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53. The state machine of Claim 57, wherein a condition for shifting directly between a 
first In-Sync State and an Acquiring Sync- State is detecting when the unique word does not 
occur at a lime it is expected to arrive. 

59. The method of Claim 26 further comprising waking up a communication link by 
driving a data line to a high state for at least 10 clock cycles and starting to transmit a strobe 
signal as if the data line was zero, by said host. 

60. The method of Claim 59 further comprising driving the data line low for SO clock 
cycles by said host while continuing to transmit a strobe signal after the host has driven the 
data line high for 150 clock cycles, 

61. The method of Claim 59 further comprising beginning to transmit the first sub- 
frame header packet by said host. 

62. The method of Claim 60 further comprising counting at least 150 continuous: clock 
cycles of the data line being high, followed by at least 50 continuous clock cycles of the 
data line being low, by said client. 

63. The method of Claim 62 further comprising searching for the unique word of the 
first sub-frame by said client. 

64. The method of Claim 60 further comprising stopping driving the data line high by 
said client after the client counts 70 continuous clock cycles of the data being high 

65. The method of Claim 64 further comprising counting another 80 continuous clock 
cycles of the data line being high to reach the 150 clock cycles of the data line- being high 
by said client, and looking for 50 clock cycles of the data line being low, and looking for 
the unique word. 
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66. The method of Claim 26 further comprising counting the number of clock cycles 
occurring until a one is sampled by said host, by sampling the data line on both the rising 
and falling edges during the reverse timing packet. 

67. A method of transferring error codes in a eomnmnication system in which digital 
data is transferred in the form of packets having CRG values between a host device- and a 
client device over a communication path comprising detecting the presence of an error, 
selecting a pre-determined error code corresponding to said error, and over-writing the CRC 
value with said code. 

68. The method of Claim 67 further comprising overwriting said CRC value in 
successive ones of packets being transferred until said error is corrected. 

69. A method of transferring digital data at a high rate between a host device and a 
client device over a communication path for presentation to a user, comprising: 

generating one or more of a plurality of pre-defined packet structures each including 
at least one CRC field, and linking them together to form a pre-defined communication 
protocol; 

communicating a pre-selected set of digital control and presentation data between 
said host and said client devices over said communication path using said communication 
protocol; 

coupling at least one host link controller residing in said host device to said client 
device through said communications path, the host link controller being configured to 
generate, transmit, and receive packets forming said communications protocol, and to form 
digital presentation data into one or more types of data packets; 

transferring data in the form of packets over said communications path using said 
link controllers; 

detecting the presence of an error for the communication link; 

selecting a pre-determined error code corresponding to said error; and over-writing 
the CRC value with said code. 

70. The method of Claim 69 further comprising overwriting said CRC value in 
successive ones- of packets being transferred until said error is corrected. 
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cond 1 = Sub-frame header packet & good CRC at frame boundary, 

Frame Length > 0 
cond 2 - no sync pattern or bad CRC at frame boundary 
cond 3 = found sync pattern, Frame Length = 0 
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cond 5 = found sync pattern, Frame Length > 0 
cond 6 = frame header packet & good CRC, Frame Length > 0 
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because they relate to subject matter not required to be searched by this Authority, namely: 
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because they are dependent claims and are not dratted in accordance with the second and third sentences ct Rule 6.4(a). 
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; | 1 Aa only someofthe required additional search fees were timely pddbythe applicant, this International Search Report 
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Continuation of Box II. 2 



In view of the large number and also- the wording of the claims presently 
on file, which render It difficult, if not impossible, to determine the 
matter for which protection is sought, the present application fails to 
comply with the clarity and conciseness requirements of Article 8 PCT 
(see also Rule 6.1(a) PCT) to such an extent that a meaningful search is 
impossible. Consequently, the search has been carried out for those 
parts of the application which do appear to be clear [and concise), 
namely claims 1 to 48, 48, 49. 



Indeed, the various definitions of the invention given in independent 
apparatus claims 26 and 42, and in independent method claims 12, 6? and 
69 in state machine claim 49, 50 and 57, are such that the claims as a 
whole are not clear and concise, contrary to Article 6 PCT. 

Furthermore* dependent claim 59 refers to claim 26 which is an apparatus 
claim whereas it reads "the method of claim 26", The same applies to 
dependent claims 60 to 66. 



The applicant's attention is drawn to the fact that claims relating to 
inventions in respect of which no international search report has been 
established need not be the subject of an international preliminary 
examination (Rule 66.1(e) PCT) . The applicant is advised that the EPO 
policy when acting as an International Preliminary Examining Authority Is 
normally not to carry out a preliminary examination on matter which has 
not been searched. This is the case irrespective of whether or not the 
claims are amended following receipt of the search report or during any 
Chapter II procedure. If the application proceeds into the regional phase 
before the £P0» the applicant is reminded that a search ray be carried 
out during examination before the EPO (see EPO Guideline C-VI, 8.5), 
should the problems which led to the Article 17(2) declaration be 
overcome. 



INTERNATIONAL SEARCH REPORT 

Intormattan on patent family roetaNsrs 


IfiisrnatioiwS A^HeailoitHo 

PCT/US2004/Q26264 


Pateifo i 


Publicaiioii 


Pdentlamliy 
msmber(s) 


Pub'lc&iion 
date' 



WO 03623587 A 26-83-2003 OS 2803033417 Al 13-02-2063 

CA 2459941 Al 20-63-2863 

EP- 1423778 A2 02-86-2864 

WO 03023587 A2 26-03-2003 

OS 2604199652 Al 07-10-2864 



US 2603833417 Al 13-92-2003 


CA 


2459941 Al 


20-03-2063 




EP 


1423778 A2 


02-06-2064 




WO 


03023587 A2 


28-03-2803 




US 


2604199652 Al 


07-10-2004 




Al) 


2735962 A 


24-06-2062 




BR 


0116157 A 


06-67-2864 




CA 


2431492 Al 


20-66-2862 




E° 


1342352 A2 


10-09-2083 




OP 


2004531916 T 


14-10-2864 




TU 


577208 B 


21-02-2064 




WO 


0249314 A2 


20-06-2862 


WO 9249314 A 26-06-2692 


AH 


2735902 A 


24-06-2002 




Bfi 


0116157 A 


06-07-2084 




CA 


2431492 Al 


28-06-2002 




EP 


1342352 A2 


10-09-2003 




JP 


' 0453101 f- l 


14-16-2864 




TW 


577208 B 


21-02-2064 




WO 


9249314 .A? 


20-66-2802 




OS 


2803033417 Al 


13-02-2963 




US 


2804199652 Al 


07-10-2864 



INTERNATIONAL SEARCH REPORT 


iraernationsl- Appitaaion Ma 

PCT/US2004/Q26264 


' ,• 

cited in searab rape it 


Publisher) 
date 


Patent family 
Humberts) 


Pubiioaiion 
date 



WO 03823587 A 29-03-2003 US 200383341? Al 13-02-2003 

CA 2459941 Al 20-03-2683 

Ei> 1423778 A2 82-06-2084 

WO 63623587 A2 26-83-2003 

US 2604199652 Al 07-10-2064 



CA 


2459941 


Al 


28-83-2093 


EP 


1423778 


A2 


82-96-2004 


WO 


63023587 


A2 


20-03-2903 


US 


2804199652 


Al 


07-18-2004 


AU 


2735902 


A 


24-06-2092 


BR 


6116157 


A 


06-87-2904 


CA 


2431492 


Al 


20-66-2002 


EP 


1342352 


Ac 


16-09-2003 


JP 


2604531916 


T 


14-10-2004 


It? 


577208 


8 


21-62-2084 


WO 


6249314 


A2 


26-86-2062 



AU 


2735982 A 


24-86-2082 


BR 


0116.157 A 


96-07-2004 


CA 


2431492 Al 


20-06-2002 


EP 


1342352 A2 


10-09-2063 


JP 


2604531916 T 


14-18-2004 


W 


577208 B 


21-82-2004 


•*e 


0249314 A2 


20-86-2062 


cs 


2633033417 Al 


13-02-2883 


US 


2004199652 Al 


87-18-2864 



FraiB PCTBBilffl!6fcB!sii» fenS/ asm* fJanuar KSS) 



